AI agents are not a compute problem. They are a data problem.
Most of the conversation around agentic AI focuses on model capability: better reasoning, longer context windows, smarter planning. That matters. But the thing that actually breaks agent systems in production is underneath all of that. It's the database.
Here's the specific failure mode. An agent needs to do three things at once: read live operational state, run analytical reasoning over historical data, and execute a transaction based on what it finds. In most architectures today, those three operations touch three different systems. The state lives in Postgres. The analytics run against a warehouse. The vector context comes from a separate store. By the time all three queries complete and the agent is ready to act, the data from the first query may no longer reflect reality. The agent acts on a picture of the world that has already changed.
This isn't a model failure. The model reasoned correctly. It reasoned on stale data.
The triangle problem
Combining OLTP and OLAP in a single system has been attempted many times. The reason it hasn't worked is what engineers call the triangle problem: you can optimize for speed (transaction throughput), scale (data volume and concurrency), or efficiency (cost per operation), but not all three without making real tradeoffs. Every previous attempt at HTAP has hit this constraint in one form or another.
The approaches that failed generally tried to solve this as a compute problem: build a faster query engine, add more memory tiers, route workloads to different compute paths. The result was always a system optimized for one workload type that tolerated the others.
A different starting point
The approach that actually works starts at the storage layer, not the compute layer. When the storage architecture is designed from the beginning to serve both row-oriented transactional access and columnar analytical scans against the same data, the tradeoffs change. The reason OLTP and OLAP conflict in traditional systems isn't that they need different compute. It's that they need different data layouts, and conventional storage can only serve one.
Combined with a concurrency control protocol that doesn't block analytical queries with transactional locks (and doesn't force analytical queries to stall transactional cleanup), you get a system where both workloads actually run concurrently rather than taking turns.
What the numbers look like in practice
Two specific benchmarks demonstrate this:
Transactional throughput under mixed load
TPC-C at 200,000 warehouses, 10 nodes, 14 cores each. 12.86 tpmC within the 99% threshold. The benchmark ran with OLAP queries executing against the same data concurrently. No degradation. Most databases that publish TPC-C numbers run it in isolation, without simultaneous analytical load.
Analytical throughput under concurrent write pressure
A JOIN across two 10 billion row tables, all rows distributed across nodes with no co-location, no indexes. Simultaneously: 50,000 ACID-compliant writes per second against the same data. 50 instances, 64GB RAM, 4 cores each. The JOIN completed in 174 seconds. Every write committed. No contention between the two workloads.
The reason that second benchmark matters specifically for agent workloads: an agent that is reading analytical context while other agents are writing state changes to the same records needs both operations to complete correctly. In a fragmented architecture, those two operations are in different systems with different consistency guarantees. In a system with a single concurrency model, they're the same transaction.
What agents actually need
Agents need three things from a database that most databases don't provide together:
Transactional correctness at concurrency. Not 10 concurrent users. Hundreds or thousands of concurrent agent instances reading and writing shared records. Serializable isolation that holds across distributed nodes, not just within a single instance.
Analytical reasoning on live data. Not yesterday's snapshot from last night's pipeline. The ability to run a complex analytical query against data that is current at query time, in the same operation as a transaction that acts on the result.
Natural language access. Agents should be able to query data the same way a person would ask a question. An MCP-native interface that lets any agent issue natural language queries against live operational data, without SQL knowledge or predefined query templates, is what closes the loop.
The full technical breakdown of how this works at the concurrency model and storage layer level is in the original post: The Shift to Agentic AI and a Modern Database
Top comments (0)