Elevate modern apps with TiDB.
Kimi’s K2.6 Agent turns a plain-language prompt into a live, hosted web application. The agent owns the full stack: Code generation, deployment, and persistent hosting. But hosting tens of millions of agent-created sites changes the infrastructure problem entirely. Each site needs an isolated database that provisions in under a second, costs near-zero while idle, and never goes cold. By deploying TiDB Cloud with a virtual database architecture, Kimi eliminates per-instance provisioning costs, delivers a fully prepared database to each agent task in under one second, and runs the entire platform on a single unified data stack.
Key Results
- Sub-1-second database provisioning for every agent task.
- Zero per-site compute cost at idle, regardless of tenant count.
- Tens of millions of concurrent tenant sites on one TiDB cluster.
- Single-instance PostgreSQL multi-schema isolation ruled out at tens-of-thousands scale.
- Frontend, backend, and database infrastructure consolidated on one technology foundation, raising agent code generation success rates.
Company Overview
Kimi is an AI product from Moonshot AI, one of China’s leading large-language-model companies. Its K2.6 agent takes an end-to-end approach to application building: From a plain-language request, the agent generates, deploys, and hosts a complete working web application, frontend and backend included. The user needs no technical background.
That scope sets K2.6 apart from tools that hand off deployment to external services like Lovable on Supabase: K2.6 owns the hosting layer end-to-end, which is what makes per-site database isolation at tens of millions of tenants tractable. It also means the platform must support a far larger user base, with each site remaining live indefinitely after creation.
The Challenge: Why Conventional Databases Cannot Support Agent-Scale Hosting
Kimi’s K2.6 Agent handles the entire application delivery chain: A user expresses a need in plain language, the agent generates code, calls a database, writes data, and launches a live application. That chain completes in minutes. The infrastructure challenge is not the code generation step. It is the hosting cost that follows.
Because K2.6 requires no technical background from users, its potential audience is far larger than developer-facing tools. The platform scales to tens of millions of sites. At that volume, three problems compound.
Fig. 1: Kimi’s original K2.6 architecture with a traditional serverless database provider.
Provisioning a Real Database Instance Per Site Is Not Viable at Scale
Each agent-created site requires isolated data storage. At the volume K2.6 operates, provisioning a dedicated database instance per site, whether Postgres, MySQL, or a managed equivalent like Amazon RDS, is not economically viable. Fixed compute per instance means idle sites generate idle costs. At millions of tenants, those costs cannot be recovered from subscription pricing.
Kimi evaluated multi-schema isolation on a single large PostgreSQL instance as an alternative. The approach hit its practical ceiling at the tens-of-thousands scale, with no path through the compounding demands of flow control, blast radius management, and data isolation that production requires.
Database Provisioning Latency Cannot Occupy the Agent’s Delivery Window
When a user submits a request, K2.6 delivers a live application in minutes. If database provisioning takes a meaningful share of that window, the agent must embed retry, polling, and wait logic in generated code. That burden belongs in the infrastructure layer, not in the application the agent produces. Provisioning must be fast enough to be invisible.
Long-Tail Tenants Require Always-On Availability Without Always-On Cost
Most agent-created sites are long-tail: traffic is infrequent, but users expect the site to load immediately when they return. Serverless architectures that reclaim idle instances introduce cold-start latency and availability gaps. Maintaining always-on real instances for millions of idle sites produces costs the subscription model cannot absorb.
The Solution: How TiDB Cloud Makes Each Agent Site Feel Like Its Own Database
Kimi’s solution separates the logical experience of an isolated database from the physical reality of shared, elastic infrastructure. Three architectural decisions shaped the build.
Fig. 2: Kimi’s K2.6 architecture with TiDB Cloud.
Eliminate Provisioning Latency from the Agent’s Critical Path
TiDB Cloud’s Warm Pool maintains a pool of pre-initialized Starter instances ready to assign. When an agent task starts, it receives a fully prepared database in under one second. Scale-to-Zero contracts the cluster during inactivity and expands automatically under load, with no manual capacity management. The agent never waits. The agent generates application code with no retry or polling logic for database availability.
Standardize the Tech Stack Across Every Agent-Generated Site
Each additional system boundary the agent must reason across introduces a new class of potential failures. By standardizing on a single database interface and a defined set of frameworks and scaffolding, K2.6 agents apply accumulated best practices rather than solving infrastructure choices from scratch on each task. TiDB’s MySQL compatibility required no query rewrites in Kimi’s application layer. Distributed SQL with ACID transaction guarantees across the cluster ensures agent state transitions remain consistent under concurrent writes from many simultaneous instances.
Replace Real Instances with a Virtual Database Layer
Rather than provisioning real database instances, TiDB Cloud places a virtual database interface between the agent and the underlying physical storage. At the physical layer, a distributed key-value store built on object storage handles data persistence. This layer provides tenant-level logical isolation and automatically manages hot-cold tiering. The agent, from inside its sandbox, sees a complete and independent database. It never encounters instance reclamation, hibernation, or connection interruption.
In the most resource-efficient state, the platform requires only a single persistent DB Session Gateway service to maintain database connections. All other resources scale elastically in response to actual demand. Sites with no traffic generate no compute cost. The architecture comparison is direct: traditional serverless databases assign each sandbox a real instance, reclaim it at idle, and cannot sustain availability guarantees at millions of tenants. TiDB Cloud’s virtual layer removes the instance entirely.
Results: Instant Provisioning, Zero Idle Cost, and a Unified Hosting Stack
- Sub-second provisioning. TiDB Cloud’s Warm Pool delivers a fully prepared database instance within one second of an agent request. Provisioning is not a visible step in the delivery chain. The agent generates application code with no retry or polling logic for database availability.
- Idle-cost elimination. The virtual database architecture removes compute spend during low-traffic periods. Inactive sites generate no idle database costs. At the scale of tens of millions of agent-created tenants, that is a material change in unit economics.
- Continuous availability. Sites remain accessible regardless of traffic level. Users do not encounter cold-start delays when returning to an infrequently visited site. The platform delivers always-on availability without always-on instance costs.
- Unified delivery stack. Frontend, backend, and database infrastructure resolve through one technology foundation. Agents apply consistent scaffolding and best practices on each generation rather than reasoning through novel system combinations. The unified stack raises code generation success rates.
- Scalable tenant isolation. Logical isolation holds across all tenants regardless of scale. The platform avoids the blast radius risks, flow control complexity, and data isolation failures that emerge from single-instance multi-schema approaches at tens of thousands of tenants and beyond.
Kimi’s assessment of TiDB Cloud reflected the compounding nature of these results. The core reason for choosing TiDB was not any single metric in isolation. It was the simultaneous delivery of tenant isolation at multi-tenant scale, a unified stack, and instant elasticity. Few systems address all three. TiDB Cloud addressed them together.
What’s Next
As Kimi K2.6 extends the scope and complexity of agent-generated applications, the volume of sites and concurrent agent tasks will grow. TiDB Cloud’s horizontal scaling ensures the virtual database layer expands without re-architecting underlying storage. The teams will focus on further optimization of the agent delivery stack, support for richer application types, and more complex backend requirements.
The architecture Kimi and TiDB established converges on a pattern emerging across agent-native commercial products: one agent, one sandbox, one database, at millions of tenants. The infrastructure competition in the agent era is not about single-point performance. It is about which systems simultaneously deliver isolation, instant provisioning, and cost elasticity when all three are required at once.
Building agent hosting infrastructure? Spin up a free TiDB Cloud Starter cluster in minutes and run agent state, tenant isolation, and elastic storage on one database.
