The Multi-Tenant Agent Database: Why the Scale Problem Just Inverted

Key Takeaways

• Coding is dead means the code is no longer the artifact that matters. The verified outcome is.
• An agent is a runtime, skills, and an environment. The environment is the part everyone ignores and the part that matters most.
• Agent workloads invert the scale problem: Not one dataset too large for one machine, but tens of millions of databases too small to each deserve one.
• TiDB X puts all data on object storage and gives every agent an isolated multi-tenant database on shared infrastructure.
• Always on does not mean always running. Keep state durable, scale compute to zero.

When an agent platform hosts tens of millions of agent-created applications, and every one of them needs a database, the traditional answer is millions of dedicated Postgres or MySQL instances. The cost of that answer is unacceptable. That infrastructure problem, not model quality, is what Ed Huang, co-founder and CTO of TiDB, put at the center of his keynote at TiDB SCaiLE Europe 2026 in Stockholm.

His argument runs in three steps. First, agents, not code, are becoming the new software. Second, agent workloads invert the scalability problem databases were built to solve. And lastly, the infrastructure that serves them has to virtualize everything, starting with the database. 

“Coding Is Dead”

Coding is dead. The claim is provocative but it does not mean software engineering disappears or software stops mattering. It means the code itself is no longer the most important artifact. The hard part now is delivering stable, reliable outcomes with AI, and doing it efficiently.

For decades, code was the bridge between a user’s intent and a durable system. An idea became a hiring plan, engineers wrote code, the code became a system, and the system produced results. Coding agents rebuild that bridge. The user describes the outcome, the agent figures out the rest, and if the outcome can be verified, nobody takes a second look at the code. Whether that is a healthy engineering practice is a separate question. It is already the working reality.

db9 is a strong proof point. It began inside TiDB as a one-person hobby project over the Christmas 2025 holiday: A new database kernel, built from scratch, with a Postgres interface. A database kernel is one of the hardest software projects there is, which made it the right test of what coding agents can actually deliver. Three months later, with a team of three people and roughly 100 US dollars a day in coding agent spend, db9 runs in production. AI generated 99 percent of the code. The system has stayed up for close to three months and supports tens of thousands of running clusters.

TiDB Co-Founder and CTO Ed Huang delivers his opening keynote at TiDB SCaiLE Europe 2026.

Why the Agent Becomes the New Software

An agent sits between the user’s intent and a live result. The user does not care about the intermediate code. The user cares that the agent understands the requirement, takes action, builds the system, and keeps the result useful. That makes the agent, not the codebase, the new unit of software.

An agent is not a chat window. A chatbot answers a question. An agent produces an outcome, because it has a computer and can take actions inside a compute environment. A working definition has three components:

• Runtime. An LLM wrapped in an agentic loop, a framework that lets the model decide what to do next. This part is not hard to build.
• Skills. The business logic and the rules for using tools, which guide the agent’s decisions.
• Environment. The computer the agent works in: Compute, storage, database, network, and the full lifecycle around them.

The environment is the component teams ignore, and it is the one that matters most. When “AI infrastructure” comes up, the reflexive answer is GPUs. The harder problem arrives when agents become the dominant form of software and a platform has to keep millions of them online. No infrastructure today is designed for that workload.

Multi-Tenant Agent Database: Why Agent Workloads Invert the Database Scalability Problem

TiDB was built 11 years ago to solve one problem: MySQL sharding pain. One large dataset, one application, scaled out without giving up SQL. Agent workloads create the opposite problem. Instead of one massive database, a platform needs millions of tiny, isolated databases, one per agent or per generated application, without turning each one into a dedicated resource. That is extreme multi-tenancy, and it is a different dimension of scalability.

Two TiDB customers make the shift concrete:

• Kimi (Moonshot AI). The Kimi platform lets a user describe a website or application in plain English, and the K2.6 agent generates, deploys, and hosts the complete working web application, frontend and backend included. The output is not source code. It is a running application with state. The platform hosts tens of millions of concurrent agent-created sites on a single TiDB cluster, and each site needs its own isolated database. Provisioning a dedicated Postgres or MySQL instance for each one does not survive contact with the cost model.
• Plaud. The AI meeting transcription company stores a massive and growing corpus of transcript data, but every user queries only their own slice, and most of the data stays cold. Traditional architectures force a trade-off. Keep everything on expensive cluster storage and absorb the cost, or split hot and cold data across different databases and absorb the architectural complexity. Plaud wanted neither.

Databases are also the leading indicator here. Whatever happens to database architecture first happens to the rest of infrastructure software later. If databases are being rebuilt for agent workloads now, the rest of the stack follows.

How TiDB X Serves Millions of Virtual Databases on Object Storage

TiDB X is the next generation of the TiDB kernel, and it already serves all TiDB Cloud users. TiDB plans to open source it by the end of 2026. The core idea is simple. All data ultimately lives on object storage, with S3 as the reference, and storage is fully decoupled from compute. Even TiKV, the storage layer, becomes stateless. 

That single architectural decision changes what the local disk is for. Instead of holding the dataset, local disks become a low-latency path for active workloads, while cold data swaps automatically to low-cost object storage. Once everything lives on S3, S3 stops being just storage and starts acting like a network, the fabric of the system. Capacity becomes effectively unlimited, and bandwidth scales with the platform.

On top of that foundation, TiDB X separates the metadata system from PD and adds a virtualization layer above the SQL layer. The result is a virtual database for AI agents. From the agent’s perspective, it owns a fully isolated database with its own mutable schema. From the platform’s perspective, every tenant shares the same underlying infrastructure. That is how Kimi serves millions of agent-created applications without provisioning millions of instances. It is built for the workload shape agents produce: Long-tail tenants, per-tenant schemas, bursty traffic, and logical isolation.

Multi-Tenant Agent Database: Why Always On Does Not Mean Always Running

The database is only the first component to go through this shift. Agents need a full environment, and the straightforward approach is to give each agent its own. At platform scale, the cost problem returns immediately, because an agent only works when it has a task. An agent sits idle close to 99 percent of the time. Dedicated environments mean paying for that idle time across the entire fleet.

The answer is a serverless principle that fits in one line: Always on does not mean always running. The endpoint and the state stay available at all times. The compute, which is where the money goes, appears only when a task arrives and scales to zero when it does not. If database virtualization works, the same principle should apply to the sandbox, the file system, the network, and the whole environment lifecycle.

TiDB is testing that idea in a research project called sys9: A complete serverless environment for agents, built on the same principle that keeps state durable while compute stays elastic. Any infrastructure system built for the agent era starts from this rule.

The Database Problem Has Inverted

The database problem of the last decade was one dataset that grew too large for one machine. In the agent era, the database problem is millions of databases too small to each deserve one. Those are not the same problem, and the second one is arriving at full speed.

TiDB X exists for the second problem: Virtual databases on shared, object-store-native infrastructure, with compute that scales to zero when the agent behind it goes quiet. Teams building agent platforms on TiDB should evaluate their database and environment architecture against the long tail now, before per-tenant cost becomes the constraint that decides whether the platform works at all.

Watch Ed Huang’s complete keynote from TiDB SCaiLE Europe 2026 for the full walkthrough of TiDB X and the shift to a multi-tenant agent database.