AI agents are reshaping the way we build and use databases

Summary:

• Agentic AI operates with limited supervision by emulating human logic at massive scale and speed, acting as a “user” that runs 24/7.
• The rise of AI agents requires a move away from permanent, centralized databases toward “microdatabases” that are task-specific, context-driven, and often deleted immediately after a job is completed.
• The primary constraint for companies has shifted from engineering time to infrastructure costs.
• Learn more about TiDB and how it is enabling the future of agentic AI databases.

You have likely heard the term “agentic AI” come up recently, but what exactly is this tech and what value does it bring over other types of AI?

It helps to think of agentic AI as the similarly named Agents from the Matrix movies. In their pursuit of the protagonist and his comrades, Agents can do any number of things within the Matrix – from commandeering vehicles to performing martial arts – taking measures as they see fit.

Similarly, agentic AI can accomplish a stated objective with limited supervision. AI agents are machine-learning models that solve problems in real time by emulating human logic, doing so at a much greater speed and scale than humans.

Ed Huang, CTO of TiDB / Photo credit: TiDB

But this faster and bigger approach to performing tasks means that databases – and how they operate – must catch up as well.

“We are facing a transformation that is far more profound: the scale of metadata, the scale of cluster count, and the scale of agility itself,” says Ed Huang, co-founder and chief technology officer of open-source database company TiDB.

Why agentic AI requires a modern database architecture

By “scale,” Huang isn’t solely referring to size; he stresses that there is a need for change in the fundamental architecture of databases. Traditional setups contain records with predefined fields that are updated periodically. These are designed for human programmers, who work only so many hours in a day and on a few tasks at a time.

However, AI agents have become the new default “user.” They are able to run 24 hours a day, work on multiple tasks at any given moment, and take into account real-time changes from the internet to keep their output up to date.

“Unlike human developers, agents do not throttle themselves,” Huang explains. “They do not batch their work to save resources, nor do they wait for off-peak periods to run heavy jobs. They generate code, ship features, spin up infrastructure, change schemas, and discard resources as casually as a human developer refreshes a browser tab.”

From TiDB’s observations, agents, not humans, accounted for more than 90% of newly created database instances. What’s more, roughly 99% of these databases were one-time use.

This shift to the “agentic user” also means that there is now a need to store every bit of information. Companies used to delete “useless” data – such as logs of every button click – to save money and storage space, but AI agents rely on these pieces of information as context to perform tasks.

For example, while there may be multiple ways for an AI agent to book a flight, keeping track of how it was exactly done allows the agent to maintain and rely on an “optimal” path to do so. The agent can even take details like layover times into account.

This means it’s now imperative to store and manage these kinds of data for AI agents to tap into.

However, storage alone isn’t an architecture problem. Agents need two distinct states, and they need them at the same time. “State” refers to the information an AI agent must “remember” in its active context to perform its functions correctly.

The transient state lives and dies with a single task, like an in-progress trip itinerary. When the trip is over, the itinerary is deleted.

Persistent state, on the other hand, is how an agent, booking your flights, remembers that you prefer aisle seats and dislike red-eye flights. This memory grows continuously and is fragmented into millions of small per-user contexts.

“Agent memory inverts the assumptions traditional databases were built on,” Huang explains. “Instead of a few large datasets queried by many users, you have millions of small datasets, each accessed by a single agent that expects the database to behave as if it were dedicated to it.”

Managing microdatabases and scaling AI workloads efficiently

The rise of agentic AI has driven a shift toward “microdatabases” designed for specific tasks. Instead of one large pool, data is organized by context, meaning every customer or product could have its own dedicated data store. When the task is completed, the agent deletes this microdatabase.

In the flight booking example, an AI agent that knows your budget, your coffee preferences, your favorite seat on a plane, and your calendar can create a microdatabase for your trip, coordinate everything, and then delete the database when you get home.

Storage and memory only matter if agents can retrieve the right context at the right moment. Unlike humans who use keywords, an agent asks the database for the closest semantic match across thousands of prior decisions. This is why vector search, a technique to find similar data points, has become inseparable from agentic infrastructure.

“Agents don’t tolerate retrieval seams,” Huang says. “If your structured data and your vector data live in different systems, you’re forcing the agent to waste intelligence and latency reconciling the two.”

Retrieval seams refer to locating and processing data within specialized frameworks.

Photo credit: WHYFRAME / Shutterstock

All this requires speed and agility. Agents don’t negotiate with the user about task requirements; they just start new experiments. Workloads are also branched out instead of consolidated.

That branching pattern carries a hard requirement: isolation.

When thousands of agents are working simultaneously, any contention between them stops the whole swarm of agents – for example, one agent’s bad test data could pollute the baseline that another agent is reasoning against.

“Sharding and multi-tenancy were designed for tenants you know in advance,” Huang says. “Agents aren’t tenants. They spin up, fork their environment, run for minutes, and terminate. The infrastructure has to give each one a clean room without provisioning a clean cluster.”

He adds that such a setup means that companies must deal with the larger costs that come with maintaining these operations, particularly in handling the thousands of microdatabases that AI agents create and delete daily.

“Agents operate databases with 1,000x the efficiency of human engineers, making cost the dominant constraint in the system,” Huang points out.

Even in these agentic workloads, certain types of data – especially personal data – still require long-term retention. This data tends to be fragmented and distributed across many small contexts.

According to Huang, this kind of long-lived yet discrete storage introduces significant cost challenges for traditional database systems.

Optimizing AI infrastructure costs and maintaining flexibility

To bridge this gap, TiDB Cloud Essential acts as a flexible foundation that grows and shrinks based on an AI agent’s needs. By separating data storage from processing power, it can create thousands of temporary microdatabases for specific tasks and then delete them the moment they are done.

Its “pay-as-you-go” approach provides the cost control companies need to keep bills from skyrocketing when AI agents start working at massive speeds.

In addition to only charging clients for what they use, TiDB Cloud Essential houses processes in one place for quicker feature turnarounds. The cost flexibility also extends to scaling of usage.

In its partnership with Manus, TiDB helped the company move to an architecture that could help agent swarms tackle complex problems by exploring thousands of solution paths in parallel. Each path needed its own database tables, schemas, and test data, and each had to run without interfering with the others.

The solution was database branching. Instead of provisioning a separate cluster for every agent or copying production data into staging environments, each agent instantly creates a branch of the parent database. The branch behaves as if it were dedicated to that agent, with all changes and tests staying local. When the agent finishes, the branch is discarded and the resources go back to the pool.

That isolation is what makes parallel exploration economically viable, removing the risk of the agents contending with others for shared resources and reducing costs significantly.

Huang emphasizes that agentic AI does not replace developers, instead amplifying the pressure on the underlying infrastructure. Solving this pressure could lead to new advancements and solutions, which is what TiDB aims to do with TiDB Cloud Essential.

“An AI database built for agents unlocks something entirely new: software that builds itself,” he says. “We are entering a world of personalized systems at massive scale, where experimentation costs pennies instead of requiring days of engineering time.”

For early-stage startups, the greatest risk isn’t just failure – it’s “the success tax” of an infrastructure that breaks the moment they go viral. TiDB Cloud provides the elastic foundation needed to power the next generation of agentic AI, allowing founders to ship faster and scale infinitely without the headache of manual sharding.

The TiDB Cloud Startup Program provides eligible startups with the credits, technical support, and community needed to turn an agentic vision into a global reality.

TRY TiDB TODAY

This content was produced by Tech in Asia Studios, which connects brands with Asia’s tech community. Learn more about partnering with Tech in Asia Studios.