Reducing the Wait Before Analysis: Why We Chose TiDB Cloud for Squadbase DB

Yuki Ogino
Yuki OginoFounding Engineer

Squadbase × TiDB Cloud

When an AI agent spots a change in the data, it should bring that change to the people who need to know and let them explore it in plain language. That is the experience Squadbase is building toward: a world where data speaks first.

People should be able to start an analysis without thinking about database setup. As Squadbase moved to organization-level connections, we reconsidered the database infrastructure supporting that experience. This model lets an organization manage its data connections centrally and reuse them across projects.

Our priorities were fast, reliable startup, regional deployment suited to our customers' needs, and sustainable costs as usage grew. TiDB Cloud fit those requirements, so we chose it for new Squadbase DB environments.

Choosing a database for organization-level connections

Squadbase DB is the built-in database our AI agents use to store and analyze data. A new project can use an existing connection within the same organization and work with the data already stored in its database.

Neon was our original choice for Squadbase DB. Its adoption by other AI services and access to the PostgreSQL ecosystem were important factors in that decision.

Organization-level connections brought a different set of operating requirements. Each organization's data needed to remain separate, with databases added as new connections were created. Setup needed to stay fast and dependable as the number of organizations and connections grew. We also considered where to store that data, balancing data residency needs, network latency, and the cost of supporting growth.

TiDB Cloud supports database initialization through SQL and offers a choice of deployment regions. Its Instance Capacity Plan supports our model of a separate instance for each organization. Together, these capabilities fit the technical and cost requirements of the connection model we were adopting.

How Squadbase organizes and initializes databases

For new Squadbase DB environments, Squadbase assigns each organization a separate TiDB Cloud Starter instance. Each connection gets its own database within that instance and can be reused across projects in the organization. The connection's credentials restrict reads and writes to that database, helping prevent an agent from accidentally accessing another connection's data.

How Squadbase organizations map to TiDB Cloud instances

On first use, Squadbase creates the organization's instance and waits for it to become active. It then creates the database and SQL user and grants the required permissions, confirming each step before continuing. Additional databases in the same organization use the existing instance.

Once the instance is active, database and user setup happen through the same SQL connection. There is no separate wait for a user created through the management API to become available for SQL access. Squadbase checks that each step succeeds before continuing and guards against duplicate instance creation.

Moving from PostgreSQL on Neon to TiDB's MySQL-compatible SQL also meant updating the database instructions given to agents and the code used to write data. Squadbase handles these differences so users can continue asking for analysis in plain language.

What changes for users

Startup speed and reliability

In our day-to-day operations, initial instance startup usually takes less than 10 seconds.

To add another database in the same organization, Squadbase connects to the existing instance and runs SQL to create the database, set up its user, and grant permissions. There is no separate application step to create or resume the instance. Teams can add a database for another use case without repeating the initial instance setup.

Reliability matters just as much as speed when someone is ready to work with data. Checking that database creation and permission setup have finished before proceeding helps make startup dependable. Whether someone is using Squadbase for the first time or starting another analysis, setup should happen in the background so they can focus on the data.

Regional placement for data residency and latency

Where a database runs affects both where its data is stored and how far each query travels. We consider data residency requirements alongside the distance between the database and our agents' execution environment.

For customers in Japan, for example, we use TiDB Cloud's Tokyo region for new Squadbase DB environments created through organization-level connections. Data stored in those databases stays in Japan. Compared with the US region used in our previous configuration, Tokyo also puts these databases closer to our agents' execution environment.

An agent queries the database repeatedly to inspect data, calculate aggregates, and check results. Even small delays on each request can add up across an analysis. Keeping the database closer to the agents is intended to reduce that wait.

Scaling with a separate instance per organization

TiDB Cloud's Instance Capacity Plan supports Squadbase DB's model of a separate database environment for each organization. As more organizations use the service, we can add instances while maintaining that separation.

A new organization receives a new instance, while additional databases within the same organization use its existing instance.

Building a foundation for data that speaks first

Squadbase is working toward an experience where AI notices changes in business data, alerts the right people, and helps them investigate in plain language. Our aim is to make noticing a change, understanding it, and deciding what to do next part of everyday work.

That experience depends on connecting automated data ingestion and updates with analysis driven by people's questions. We are building on organization-level connections so the same shared data can support both agents detecting changes and people investigating their causes.

TiDB's ability to handle data updates and analytics in the same database fits this direction. As data volumes grow and analysis becomes more frequent, responsive analysis and sustainable operating costs remain priorities. With TiDB supporting this foundation, we can extend this way of working with data to more areas of a business.