Are Databases Ready for Agentic AI?

At a time when agentic AI is rapidly reshaping how software behaves, Arpit Bhayani, creator of DiceDB, makes a compelling argument. He believes databases were never designed for this new, agent-driven world.

Drawing on his latest experiments with agentic workloads, Bhayani brings attention to a deeper change unfolding beneath the surface.

“Databases are the most brittle component of our architecture,” he says, speaking at MLDS 2026, India’s largest agentic AI conference organised by AIM. “They make the system, they break the system.”

The Illusion of Determinism

For decades, databases have operated under a simple, unspoken assumption of predictability. Engineers knew what queries would run, how tables would be joined, and which indexes to build.

That assumption is now breaking.

“We always assumed a deterministic caller,” Bhayani explains. “You know the kind of queries your system will fire.” 

Agents don’t follow that script. 

“With an agent, because the input is natural language, you don’t know what kind of SQL query it’s going to output,” he says.

A query joining five unrelated tables, once unthinkable in a controlled system, becomes entirely possible. The result is not just inefficiency, but deep unpredictability in the data layer itself.

When Time Stops Being Short

Traditional systems treated database interactions as brief. Queries ran in milliseconds, connections opened and closed quickly, and transactions were tightly scoped.

Agentic systems change that rhythm entirely.

“LLMs think a lot,” Bhayani says. “They take time.” That delay stretches transactions and keeps database connections open far longer than they were designed for.

“Your transactions can span a long time, your SQL query can become very expensive because you don’t know what the agent is going to fire,” he explains.

What follows is a subtle but dangerous shift. Connections sit idle, waiting for the agent’s next move, while new sub-agents multiply in the background. “It’s like an amoeba,” he notes. “Two, four, eight, sixteen… suddenly your database is constrained not by CPU or memory, but by connection limits.”

When Failure Doesn’t Look Like Failure

In traditional systems, bad queries fail loudly. Errors are thrown, exceptions are handled, and systems recover predictably.

Agents, however, blur that clarity.

“We always thought bad queries would fail, but in an agentic workflow, that is completely untrue,” he says

A query with the wrong condition might return an empty result set instead of an error. For an agent, that empty response can look perfectly valid.

This ambiguity introduces a new class of silent failures, where systems continue operating on incorrect assumptions without any explicit signal that something went wrong.

Rebuilding Guardrails for an Unpredictable World

To navigate this uncertainty, Bhayani advocates for a more defensive data layer. One that is not reactive, but intentionally constrained.

One approach is to rethink deletion. “Soft delete everything,” he says, emphasising the need to track not just when data was deleted, but by whom and why. 

In an agent-driven system, where multiple actors can modify state, this context becomes critical.

Another shift is towards append-only systems for high-stakes workflows. “Your updates are projections,” he explains. Instead of overwriting data, systems record every action, making it possible to reconstruct or reverse decisions when agents go wrong.

Retries, a common behaviour in agentic workflows, introduce further complexity. “Agents retry a lot,” Bhayani notes. Without safeguards, the same action could be executed multiple times. This is where idempotency becomes essential, ensuring that repeated attempts do not create unintended side effects.

Observability Becomes Survival

If unpredictability is the new normal, visibility becomes the only way to stay in control.

“You need to know who fired the query, for what task, at what step,” Bhayani says. Traditional monitoring of slow queries is no longer enough. Systems must trace actions back to specific agents and workflows.

This level of observability is not just about debugging performance. It is about understanding behaviour. If an agent generates inefficient or incorrect queries, the root cause may not lie in the database, but in the prompt, the tool, or the workflow design itself.

Rethinking Schema as Communication

Perhaps the most overlooked shift lies in how schemas are designed.

“Schema used to be a contract with engineering,” Bhayani says. Column names like usr_id or flg_y were acceptable because humans understood them.

Agents do not.

“You can’t rely on agents to figure it out.” Instead, schemas must become explicit, descriptive, and enriched with metadata. A column should not just store data but also communicate intent clearly enough for an autonomous system to interpret correctly.

Limiting the Blast Radius

As agents gain more autonomy, the risk of unintended actions grows. Bhayani argues for reviving an old principle: strict access control at the database level.

“Create multiple roles for multiple agents,” he suggests, each with minimal and specific permissions. If an agent does not need access to certain columns or tables, it should not have it.

A New Reality for the Data Layer

What emerges from Bhayani’s talk is not a rejection of agentic systems, but a call to rethink the foundations they rely on.

“Agents don’t break your database,” he says. “They expose assumptions you didn’t know you had.”

That may be the most important takeaway. The fragility we are seeing is not new. It has always existed, hidden beneath predictable workloads and controlled inputs.