Kimi.ai has selected TiDB to provide the persistent data infrastructure for its AI agent platform, a deployment intended to support tens of millions of AI-generated applications.
Developed by Moonshot AI, Kimi.ai lets users describe an application in natural language, then generates the front end, back end and database before deploying a live application within minutes. That model creates a database challenge because each generated application needs persistent storage without the cost of running a separate database instance for every low-traffic app.
Kimi.ai chose TiDB Cloud Starter after finding that more conventional database approaches were difficult to sustain at large scale, according to TiDB. A dedicated database for every application would have raised costs sharply, while a multi-schema model on a single PostgreSQL instance reached practical limits at the scale of tens of thousands of applications.
The set-up is designed to provision isolated databases in about one second, removing database creation from the delivery path when an AI agent builds and launches a new application.
Scale challenge
The arrangement reflects a wider shift in AI software as agents move from answering prompts to creating and maintaining complete applications. That change increases the need for persistent data, state management and hosting that can remain available even when the underlying compute environment is temporary.
Under the model TiDB described, Kimi.ai can give each AI-generated application what appears to be its own independent database without assigning each tenant a separate physical instance. A virtual database layer provides logical isolation, while storage is shared and scaled according to demand.
TiDB said its Warm Pool feature can provide a prepared database to an agent task in less than one second. Kimi.ai also uses its persistent filesystem technology to preserve development state across short-lived execution environments.
That means AI coding agents can retain source code, Git history, checkpoints and task progress after compute environments are destroyed, then resume work across sessions. The approach also reduces the number of infrastructure choices an AI agent must make when generating an application because the front end, back end and database sit on a standardised base.
The database's MySQL compatibility was another factor in the deployment. TiDB said this allows applications to use familiar drivers, tools and frameworks, which can simplify software generation by AI systems.
Industry pattern
The case points to a growing infrastructure pattern for AI-native software, in which compute is temporary and elastic but data and development state remain persistent. That differs from traditional application design, where a database instance is often tied more closely to a single application environment.
For companies trying to support very large numbers of AI-generated applications, the economics of idle workloads have become a central issue. Many applications created automatically may remain online but receive little or no traffic, making a one-instance-per-app approach expensive and operationally difficult.
TiDB said its architecture addresses that by removing idle database compute costs for inactive applications while keeping applications continuously available without the cold starts often associated with serverless systems. It added that a single TiDB deployment can support tens of millions of isolated tenant applications.
Ed Huang, Co-Founder and CTO at TiDB, described the infrastructure demands created by this shift in AI software.
"AI agents are fundamentally changing what infrastructure must deliver. Applications created by AI need databases that appear instantly, remain continuously available, and scale economically to millions of deployments. That's exactly what TiDB was built to do," said Huang.
Kimi.ai's use of the technology highlights how database design is becoming a more visible part of the AI application stack as software agents take on more of the work of building and operating live services. In this model, the challenge is no longer only generating code, but also creating a data layer that can be provisioned quickly, persist reliably and remain economical at very large scale.
The deployment supports isolated databases in about one second, continuous availability for AI-generated applications and persistent development state across sessions, according to TiDB.