AI agents are no longer a thought experiment. They’re already writing code, calling APIs, retrying failed requests, and coordinating work at machine speed. And they’re about to put unprecedented pressure on the systems we use to store and move data.
That was the core theme of a recent Cockroach Labs webinar, “The Future of Databases for AI Agents” featuring a fireside chat between technical evangelist Rob Reid and co-founder and CEO Spencer Kimball. The discussion explored what agentic AI means for databases, why legacy infrastructure is already showing cracks, and what “data readiness” looks like in a world where machines, not humans, are poised to become the primary source of traffic.
Below are the key ideas that stood out.
From human scale to agent scale
For the last few decades, databases have evolved to keep up with people: first on desktops, then laptops, then mobile devices. Each shift drove a step change in traffic, but there was always a natural ceiling, the number of humans on the planet and the pace at which they interact with software.
AI agents remove that ceiling.
As Spencer put it, we’re moving from billions of humans to potentially tens or hundreds of billions of agents, all interacting with back-end systems autonomously. Unlike people, agents don’t sleep, don’t wait between clicks, and don’t follow predictable usage patterns. An agent that decides to retry, fork, or validate its own work can generate thousands of requests per second, per agent.
This won’t be theoretical forever. The tooling already exists. What’s missing, today, is infrastructure that can absorb that kind of demand without falling over.
Why “eventual consistency” won’t survive agents
One of the most direct claims in the conversation was this: agentic AI spells the end of eventual consistency for operational databases.
Eventual consistency has worked mostly because humans are slow and forgiving. If a balance takes a moment to update, or a UI briefly shows stale data, most users don’t notice or will tolerate it (for the right product).
Agents are different. They react instantly to inconsistencies. If they read incorrect or stale data, the agent won't know that the data is stale, so will act on it as though it isn't. That behavior can quickly turn a small inconsistency into a cascading failure.
In an agent-driven world, databases must provide:
Strong, serializable consistency
Correct answers on every read
Predictable behavior under extreme concurrency
Anything less becomes a liability, both operationally and, increasingly, from a security standpoint.
The real breaking point: cost at scale
Resilience and correctness are hard problems, but Spencer argued that cost may be the hardest problem of all.
If AI agents increase transaction volume by 10x, 50x, or 100x, simply scaling today’s architectures linearly isn’t viable. Databases are already expensive. Multiply that cost curve by two orders of magnitude and many systems become economically unsustainable.
This is where distributed architecture matters. A database built to scale elastically, adding and removing capacity without downtime, has more room to optimize for cost efficiency as usage grows. Spencer’s prediction was blunt: the database that wins the agentic AI era will be the one with the lowest total cost of ownership at massive scale.
Not the cheapest at small scale. The cheapest when all cylinders are firing and everything that can fail is failing.
Data readiness for the agentic era
So what does a data architecture need to look like to survive and thrive with agentic AI?
Several themes came up repeatedly:
Elastic scalability: Scaling can’t require maintenance windows, table locks, or vertical resizing. Capacity has to be added and removed live, under load.
Always-on operations: Planned downtime becomes far more expensive when millions of agents are interacting with your system continuously.
Strong consistency at global scale: Agents depend on correctness. Serializable isolation is table stakes.
Unpredictable burst handling: Agent behavior has the potential to be spikier than human behavior due to sheer volume. Infrastructure must absorb sudden, unplanned surges without manual intervention.
Cost efficiency as a first-class concern: The economics of AI-driven traffic matter as much as the technical feasibility.
Where CockroachDB fits
Throughout the conversation, CockroachDB came up not as an “AI database” or even a vector database – it’s not – but as a system designed for the conditions AI agents create.
Distributed from day one, CockroachDB combines:
Strong consistency
Horizontal scale
Built-in resilience across nodes, regions, and clouds
PostgreSQL compatibility, so teams don’t need to relearn everything to get started
For teams experimenting with AI — whether that’s semantic search, natural language interfaces, Retrieval-Augmented Generation (RAG), or their first agents — this foundation matters. As those experiments move into production and traffic ramps up, the gap between legacy infrastructure and cloud-native, distributed systems becomes impossible to ignore.
The shift happens fast
One final point stood out: the pace of change.
Previous platform shifts took years, sometimes decades. AI adoption is happening faster. Tools are improving monthly. Agents are already writing and operating software. And as switching costs drop, loyalty to systems drops with them.
Agentic AI isn’t just another workload. It’s a forcing function that will push databases, architectures, and cost models to their limits.
The question isn’t whether this shift is coming. It’s whether your data infrastructure is ready when it does.
