Nobody Can Plan the Future of Infra: TiDB’s AI Evolution Journey

Looking only at the results, TiDB’s product form has changed rapidly in the AI era.

From a database, to a Serverless database; from a database that an agent can create and destroy on demand, to a file system, cloud disk, and coding workspace; and finally gradually becoming a unified storage layer oriented towards agents. Going further up, through the agent stack solution, it makes it easier for users to build their own agent applications, and truly makes TiDB an important part of agent infrastructure.

This sounds very much like a grand, pre-designed strategy.

But the real situation is usually less dignified.

We didn’t sit around a conference room table and say, “Guys, next step, we’re going to do agent infrastructure.”

The more realistic scenario is:

We were pushed step by step here by customer demands – each one seemingly a bit absurd at first, but making total sense upon closer inspection.

This is also the most interesting part of infrastructure products. Real change often doesn’t start with a beautiful concept, but rather with a customer saying:

“Hey, can you just solve this one thing for us too?”

And that’s how it begins.

The Origin: Taking Complexity Away from Application Developers

The problem TiDB originally aimed to solve was simple: MySQL sharding was too painful.

Back in the days of China’s high-speed internet growth, a single MySQL instance couldn’t handle the data volume and concurrency. Business teams had to implement sharding themselves. So application developers weren’t just writing business logic; they also had to deal with routing, sharding, scaling, complex queries, operations, and consistency issues.

People who were supposed to be writing business logic ended up becoming half-baked database kernel engineers.

TiDB’s core value was to sink this complexity – which shouldn’t be on application developers’ shoulders – down into the infrastructure layer.

This origin point is crucial.

Because in the AI agent era, the problems have changed, but the logic hasn’t.

Previously, we wanted to eliminate the sharding nightmare for application developers.

Now we want to eliminate the nightmare of state, context, files, workspaces, and runtime environment management for AI developers.

Essentially, it’s the same old saying:

Application developers should focus on business, not be stuck constantly fighting with infrastructure day in and day out.

What follows are the stages where this logic was continuously amplified by customer needs.

Phase One: AI Companies as “Regular Database Customers”

The earliest type of AI customer wasn’t that mysterious.

They had large amounts of user conversations, application metadata, model invocation records, and business states to store. Early on, MySQL or PostgreSQL could handle it, but once the business exploded, and data volume and access rates grew, they were back to the old problem:

Should we shard or not?

This sounds familiar, almost retro.

No matter how cool an AI company is, when database scalability falls short, they inevitably return to that age-old question: the single machine can’t handle it, what now?

So these customers migrated the complexity of MySQL/PostgreSQL sharding onto TiDB. Essentially, this was TiDB’s most familiar old problem:

Data scale grows too fast, and the application layer no longer wants to bear the blame for database scalability.

At this stage, our understanding of AI was still relatively shallow. It seemed AI companies using databases were no different from traditional internet companies: too much metadata, too much access volume, a single database couldn’t cope.

But soon, customers started making requests that didn’t sound like “normal database requirements.”

Phase Two: One User, One Database

Dify proposed a very critical requirement:

Can you give each user an independent database?

Traditional SaaS design typically shares one database among multiple tenants, distinguishing data by tenant_id. This model is mature and cheap, but in AI workflow scenarios, it exposes many problems:

• Poor isolation: If one database fails, it can impact many users.
• High security risk: If application logic is written incorrectly, data cross-reading between tenants can occur.
• Difficult billing: It’s hard to calculate individually how much database resource each user consumes.
• High change risk: A change for one tenant might affect others.

So Dify wanted “one user, one database.”

This was a clear challenge for TiDB.

Previously, we were mostly solving “how to make one database larger.” Now the customer was asking:

Can you manage hundreds of thousands, or even millions, of databases?

This step was crucial.

It pushed TiDB from “making a single database bigger” to “managing a massive fleet of databases.”

But at this stage, the business logic was still relatively consistent. Each of Dify’s users had their own workflow, but the table structures and usage patterns were broadly similar.

The truly more radical shift came from the next type of customer.

Phase Three: Agent Becomes a First-Class Citizen of the Database

Later, top-tier agent platforms like Manus proposed an even more radical requirement.

They also wanted a million databases.

But this time, it wasn’t for a million workflows with similar structures. It was for a million applications generated by agents.

A user might ask an agent to generate a blog system, CRM, internal tool, or even a small SaaS. Each application would have its own business logic, schema, query patterns, and lifecycle.

This was completely different from Dify’s scenario.

Dify’s challenge was scale and isolation.

The challenge in scenarios like Manus was:

The user of the database is no longer a human-written application, but the agent itself.

The agent has to create its own database, generate its own schema, write its own business code, generate its own query logic, and decide when to create, modify, and destroy.

At this point, the database can no longer assume that:

• Schema is pre-designed by humans;
• Query patterns are optimized by engineers;
• Instance lifecycles are long-term stable;
• Operational tasks are controlled by humans.

Previously, databases faced human engineers.

Now, the database faces an agent that can write code, create tables, modify schemas, and might suddenly destroy the environment at 3 AM.

This is a new type of user.

The database must start treating agents as first-class citizens.

This was a leap in product mindset.

Before, TiDB was a database serving human engineers and human applications.

From this stage on, TiDB had to serve a new entity: an agent that writes its own code, creates its own tables, runs its own queries, and destroys its own environments.

Phase Four: The Database Begins to Resemble a File System

Next, a customer making smart recording devices asked a very counterintuitive question:

Can your database store our files?

To a traditional database engineer, this sounds a bit like:

“Hey, can your refrigerator also double as a garage?”

Databases typically store structured data and metadata. Large files like audio, video, and images are usually kept in S3 or object storage.

Typical AI application architecture follows this pattern:

• Audio/video files go to object storage;
• Summary, tags, transcripts, embeddings, metadata go to the database.

This architecture seems reasonable.

But at scale, problems emerge:

• Metadata itself becomes a scalability bottleneck;
• Files and metadata live in two different systems, making consistency prone to issues;
• Object storage latency is relatively high, hurting user experience;
• To solve latency, customers have to implement their own caching;
• As the cache grows, they must handle hot spots, scaling, disaster recovery, and consistency.

Eventually, the customer realizes:

To make the “file + metadata” system work stably, they’re essentially building another complex distributed system on their own.

This circles right back to TiDB’s old proposition:

Application developers shouldn’t pay the price for infrastructure complexity.

TiDB itself is a distributed database. Its underlying engine can also use object storage, while offering distributed transactions, metadata management, scalability, and hot spot handling. So a new product form began to emerge:

A database isn’t just a database; it can also become a file system.

This step pushed TiDB from “structured data storage” toward a larger “unified storage engine.”

Phase Five: File System Becomes Agent Runtime Workspace

After the file system, the coding agent scenario pushed the requirements even further.

Customers like Kimi and Verdent started asking:

Since TiDB can be a file system, can you provide a cloud disk for agents?

The reason is simple: coding agents typically run in sandboxes, and sandboxes are often stateless.

If the sandbox crashes, the task state, code modifications, runtime environment, and context could all be lost.

Agents need a persistent workspace to save files, state, and context during their work.

But a coding workspace isn’t just a regular cloud drive.

It has a very special workload: Git.

Git generates a huge number of temporary files, objects, indices, diffs, commits, clones, and checkouts. If a regular cloud drive directly hosts a Git workflow, it easily runs into performance, cost, and consistency issues.

So what the customer really wants isn’t just “a mountable drive.”

What they truly need is:

A workspace that understands agent coding workloads, understands Git, can be mounted on a sandbox, and can restore task states.

At this point, TiDB took another step forward.

It wasn’t just a file system anymore; it was a workspace for the agent runtime.

This step was crucial because it pushed TiDB from “storing data generated by agents” to “hosting the agent’s working process.”

Phase Six: Unified Storage Layer

Initially, TiDB, as a distributed OLTP database, solved the scalability problem for traditional OLTP.

Later, to help customers with real-time analytics scenarios, TiDB evolved into an HTAP database.

In the AI era, the demands continued to change.

AI applications don’t just need to store tables.

They need to store state, context, files, embeddings, transcripts, metadata, workspaces, runtime processes, audit records, and even connect to more complex data lake and lakehouse scenarios.

This is the backdrop for capabilities like TiDB Lake.

The data landscape of AI applications is naturally hybrid:

• Business state requiring strong transactions;
• High-concurrency online queries;
• Massive historical data;
• Files and objects;
• Vectors and semantic search;
• Real-time analytics;
• Offline training and evaluation;
• Large amounts of intermediate state generated by agent runtimes.

If you use a separate system for each data type, developers end up facing not an infra stack, but an endurance race in system integration.

So TiDB’s evolution direction at this stage is to combine the capabilities of a distributed database, file system, workspace, and data lake into a unified storage layer.

It’s not simply saying, “I also support more data types.”

More precisely, it’s answering one question:

Can AI applications and agent systems stop building a separate infrastructure stack for every type of state, file, context, and analytical need?

That’s the value of the unified storage layer.

It allows agents and AI applications to manage different data forms on the same infrastructure:

• Online state;
• User data;
• File content;
• Workspace;
• Context;
• Audit logs;
• Analytical data;
• Long-term memory.

After this step, TiDB’s role became more than just a “database.”

It started becoming the unified storage layer behind AI applications.

Expansion Stage: From Unified Storage Layer to Agent Stack

The customers in the earlier stages were mostly top-tier AI companies.

They had strong engineering capabilities; they just needed TiDB to provide underlying capabilities like databases, file systems, cloud disks, and workspaces.

But later, many small and medium AI companies also came knocking.

Their problem wasn’t:

“Can you give me a database?”

It was:

“Can I avoid building an agent system from scratch?”

A truly production-grade agent system is more than just an LLM API.

It typically includes at least:

• Agent core: Claude Code SDK, Kimi Code, OpenAI Codex, etc.;
• Sandbox/runtime: allowing the agent to run tasks safely;
• Memory/state/workspace: short-term memory, long-term memory, files, workspace;
• Model/API gateway: routing, cost, and capability selection for different models;
• Observability: logging, monitoring, debugging;
• Audit/governance: permissions, auditing, compliance;
• Billing: resource metering and cost control.

Large companies can build this themselves.

Small and medium AI companies find it very difficult.

Especially for hardware AI, emotional companion, and vertical application companies, their core strengths might be in products, hardware, content, scenarios, and user understanding – not in building agent infra from scratch.

Making them build a complete production-grade agent infra from zero is basically like asking a coffee shop to first build its own power grid.

So the demand at this stage became:

Can you provide a complete agent stack so I only need to focus on my own business logic?

At this point, TiDB’s positioning continued to evolve.

Not to do everything, but to act as a unified storage layer core (database, file system, workspace, state storage), combined with ecosystem components like sandboxes, agent cores, model APIs, observability, and billing, becoming one of the entry points into agent infrastructure.

This isn’t a simple platform narrative.

More accurately:

When agents truly go into production, they need a unified infrastructure stack. TiDB is evolving from the unified storage layer within that stack into one of the entry points for developers to access that stack.

The Unified Logic Behind These Stages

On the surface, these stages seem vastly different:

• From MySQL/PostgreSQL sharding;
• To a million databases;
• To agents creating databases autonomously;
• To a file system;
• To a sandbox runtime workspace;
• To a unified storage layer;
• To an agent stack.

But the underlying logic is consistent:

Customer business complexity keeps rising, and TiDB continuously absorbs that complexity from the application layer, sinking it into the infrastructure layer.

Ten years ago, the complexity was sharding.

Today, the complexity is agent state, context, files, workspaces, permissions, auditing, runtime environment, and cost.

This is also why the term “AI database” isn’t precise enough.

What TiDB truly needs to do in the AI era is not just add a bit of AI capability to a database, nor simply build a vector database. It is to become the unified storage layer behind agents and AI applications:

• State can be saved;
• Context can be queried;
• Files can be managed;
• Workspaces can be restored;
• Permissions can be governed;
• Operations can be audited;
• Costs can be measured;
• Scale can be extended.

This is the real story TiDB should tell in the AI era.

Not “Databases can do AI too.”

But:

AI applications have finally pushed infrastructure complexity to a new level, and TiDB is catching that complexity.

Finally

The best roadmap for an infrastructure product is often not planned, but forced by customers.

But the prerequisite is that you can understand the real problem the customer is asking.

When a customer says “I need a million databases,” the real issue might be isolation, billing, and blast radius.

When a customer says “Can the database store files?” the real issue might be metadata, object storage, consistency, latency, and caching complexity.

When a customer says “Can you give me a cloud disk?” the real issue might be stateless sandboxes, Git workloads, and agent workspace recovery.

When a customer says “Can you give me an agent stack?” the real issue might be that small and medium AI companies lack the ability to build production-grade agent infra from scratch.

So TiDB’s AI evolution is not about packaging a database into an AI concept.

It’s more like an infrastructure evolution path pulled by customer demands:

From storing data, to storing files, to storing workspaces, to storing agent runtime state, and finally becoming part of agent infrastructure.

No one can plan the future of infrastructure from the start.

Most of the time, the future is first shouted out by customers.

All you can do is not dismiss that demand as absurd. Listen carefully, then roll up your sleeves and get to work.