What a database for AI agents needs is already clear

In a recent interview with The Register (https://www.theregister.com/databases/2026/09/18/the-ideal-database-for-ai-agents-doesnt-exist-yet-says-percona-ceo/5296906), Percona CEO Peter Farkas argued that the ideal database architecture for AI agents remains unbuilt, and that the agent ecosystem must mature before a purpose-built system can be designed from scratch. He is right that key aspects of agent deployment, such as governance frameworks and operational boundaries, are still in flux. The data layer requirements for an AI database are already clear. The scenario he described shows what these workloads demand.

A data layer for AI agents has to meet three requirements at once, directly on operational data. First, Composability lets it answer ad-hoc queries that nobody wrote in advance. Second, Concurrency lets it serve queries from many people and agents at the same time. Third, Consistency means every query sees the current operational state, so a check and the action that follows it read the same data. Many databases handle one or two of these. Agents that take business actions need all three.

Long before AI agents emerged, transactional systems like real-time fraud evaluation and algorithmic risk controls, including those powered by machine learning, ran into the same requirements. What agents add is queries that software composes at runtime, with far more of them running at once.

Database requirements for agentic AI and multi-attempt agent workloads

Farkas outlined a scenario where an AI agent generates 150 candidate solutions for a single task before a human or downstream system picks the best one. No human operator would try that many options. Each attempt triggers one or more queries against enterprise data, which produces a workload traditional databases were not designed for.

The queries change from one attempt to the next. A single workflow might start by checking active customer orders against available inventory, then join current shipping disruptions with years of return history to decide whether an alternative product can be safely offered. The agent composes these queries at runtime, so precomputed views and caching layers don't help, and the database has to compute every answer on the fly.

They also arrive at the same time. A single task turns into hundreds of queries, and when a fleet of agents in a multi-agent system runs alongside existing users and applications, concurrent load climbs fast. Transactional systems have long handled high concurrency by serving predictable, indexed key-value lookups. When agents issue unpredictable queries at scale, the database needs indexing that limits each scan to the relevant data. Without it, agent traffic slows down everything else on the system.

Once an option wins, the agent makes an operational change, such as locking stock or placing a hold, which has to take effect immediately on the live state of the business. If two agents read inventory levels from separate, out-of-sync replicas, both could see the last item as available and try to claim it. Each decision was correct for the snapshot it read, and the same item is sold twice.

Farkas noted a similar problem in model design: a system that attempts every task costs more to run than the value it delivers. The same holds for the data layer. When 149 out of 150 query runs are discarded, the organization pays for 150 rounds of compute to get one result. At that ratio, the cost of each query becomes an engineering constraint. Running attempts against redundant copies of the data multiplies infrastructure spend, and the pipelines that sync those copies run continuously, whether or not anyone keeps an attempt's output.

What is Active Data Intelligence?

Active data is the live operational data a business runs on, such as pending orders and current account balances. Streaming data is a live copy of events as they pass through a pipeline. Active data is updated in place as orders and balances change, and it consistently represents the current state of the business. Active Data Intelligence brings composable analytics to that operational data at the concurrency agents generate, so people, automated systems, and autonomous agents can analyze the business as it stands and act on it in the same system. With no intermediate copies, the path runs directly from data creation to analysis, decision, and action.

It depends on the three requirements in Farkas's example:

• Composability: The ability to run any query on demand, including joins that combine live transactions with years of history.
• Concurrency: The ability to serve a high volume of requests at once from users, applications, and autonomous agents, using indexes to keep the cost of each query low.
• Consistency: The guarantee that every query sees the same current state of the system, so validation and the action that follows it work from the same data.

Established data systems often meet one or two of these requirements. Warehouses answer any question for a small team of analysts, and transactional databases handle heavy concurrency for questions known in advance. Many workloads need composability and concurrency together. A software company that builds analytics into its product has thousands of its customers asking their own questions at once, and a few seconds of lag rarely matters to them. Agents that act on the business need consistency as well.

Running directly on operational data matters because every intermediate copy adds a delay between the analysis and the current state. Traditional decision pipelines still run on replicated data, such as nightly warehouse syncs or caching layers. That lag works for people who decide over hours or days. It fails when software and agents have to act within milliseconds.

Can a database for AI agents be mature yet?

Farkas argues that we should wait for databases to mature, noting that established, trusted database platforms took decades to prove themselves, and systems built for AI agents haven't had that time yet.

I spent four years at Mesosphere during the shift to containers, and my team moved our product suite to Kubernetes. Kubernetes published its first code to GitHub in June 2014. Its design came from Borg, the cluster manager Google had run internally at scale for nearly ten years, and many of its engineers had worked on Borg. The code was new, but its requirements had been proven at Google's scale for a decade. Requirements and code mature on different timelines, and the requirements often mature first.

The database requirements for agents followed the same path. Well before AI agents, software took over high-stakes decisions that people used to make, such as checking card transactions for fraud and enforcing risk limits on trading desks. These systems make thousands of decisions per second at millisecond latency, and stale data costs them money right away: fraud caught after approval is already a loss, and a risk check that reads a minute-old snapshot can let through concurrent trades that breach a limit. Databases built for these workloads have run in production for more than ten years. SingleStore, which launched as MemSQL in 2011, is one of them.

A large US bank running SingleStore moved its fraud detection from overnight batch jobs into the live transaction path. Its system now runs about 70 distinct queries in 50 milliseconds, well inside the one-second budget for approving a transaction. That is the database profile of an AI agent: many targeted queries about one entity, across live and historical data, under a tight latency limit, where the answer decides whether a payment goes through.

The difference is predictability. The bank's engineers wrote and tuned every one of those 70 queries in advance. An agent writes its queries at runtime, so nobody can precompute or tune them one by one. Regardless of which AI models power them, agents inherit the latency and concurrency requirements that fraud and trading systems proved out, and have to meet them with queries nobody planned.

Which agent workloads need composability, concurrency, and consistency at once

Different agents need different things from a database. Four patterns come up often in enterprise agent pilots.

Agent pattern

Example

What it needs from the database

Retrieval

A support agent searching policies and past tickets to answer a customer

Fast hybrid search over documents and records. It reads and rarely changes state

Analysis

An agent testing explanations for a revenue dip across dozens of queries

Composability and concurrency. A recent copy is often acceptable when a person makes the final call

Monitoring

An agent watching a stream of events for anomalies and raising alerts

Questions mostly known in advance, which stream processing handles well

Operational action

An agent that reroutes shipments or places holds

All three: it reads the live state, composes questions nobody planned, and changes data other agents and applications depend on

Retrieval and monitoring agents run well on standard infrastructure, such as vector indexes, vector databases, and stream processors. A fleet of analysis agents needs composability and concurrency together, the same pair as analytics built into a product. Warehouses built for a small team of analysts handle the first and only part of the second. Operational action needs all three at once, and wrong data there turns directly into financial loss.

Agents also tend to move toward operational action over time. A support assistant answering questions today may be authorized to process refunds tomorrow. An analytical agent explaining revenue swings may later move budget. A monitoring agent that flags anomalies may start placing holds. More authority means stricter data requirements. An agent that changes data has to stay consistent with every other system acting at the same time, while the whole fleet keeps composing its own queries.

Choosing a data architecture for agentic AI now is a decision about what your agents will be allowed to do later. Retrieval works on copies. Once agents can act, an organization either migrates to live data under deadline pressure or is already running on infrastructure built for it. Until organizations settle how far to trust agents, the safer choice is a foundation that handles today's queries and can take on the actions that come later.

What makes an AI database?

At the end of the interview, Farkas restated Percona's stance against simply rebranding Postgres or MongoDB as "AI databases." I agree, for architectural reasons.

The usual way to adapt an existing database for AI is to add capabilities around the engine: vector extensions, search indexes, or ETL pipelines to mirror operational records into data warehouses. Each addition works, and each one adds another copy of the data on its own sync schedule. Vector indexes trail their underlying tables. Analytical warehouses lag primary transactional systems. An agent that queries all of them before acting sees three different versions of the business.

Data engineering has seen this problem before. In 2011, Nathan Marz described what became known as the lambda architecture, which ran a batch path and a speed path side by side to get both completeness and freshness. It worked, but teams had to maintain two code paths that could disagree. Agent architectures built on copies bring back the same tradeoffs. The risk is higher now, because an agent can act before a person has a chance to catch the mismatch.

Running separate engines over shared storage solves part of this. Each engine still has its own transaction boundary, so a check in one engine and the action in another can see different states. Those gaps show up later as breached exposure limits or oversold inventory.

SingleStore is an operational database built for Active Data Intelligence. It runs transactions, analytics, full-text search, and vector search in one engine on live data, so applications and agents can read state and write in a single ACID transaction, such as checking inventory and reserving stock in the same step. New writes go into memory as rows, then move into compressed, indexed columnstore, which keeps ad-hoc queries fast at high concurrency. As data ages, it tiers from local SSDs to object storage in open formats like Apache Iceberg, reducing query costs without altering analytical results.

Traditional systems of record and data warehouses still handle long-term auditing and model training on historical data. Workloads that decide and act in real time, including AI agents, need a single live data foundation.

Key questions for evaluating a database for AI agents

Skip the labels and test platforms against the demands of the agent execution loop. Ask any vendor these questions, including us:

• Query adaptability & latency: can the AI database run ad-hoc queries that join live operational data with years of history fast enough to fit inside an agent's loop?
• Fleet concurrency: how do response times hold up when a large multi-agent deployment runs these queries alongside production applications?
• Transactional isolation: when an agent checks a condition before it acts, are the check and the action guaranteed to see the same snapshot, or can other agents change the state in between?
• Replication & lag: how many intermediate data copies exist between the AI application and the primary system of record, and what is the synchronization delay for each?
• Unified governance: is one access control policy enough to govern every path used by agentic AI, including point lookups, vector and text search, and broad analytical queries?
• Post-action auditability: can the system reconstruct and verify the exact data the agent read when it committed an action?

Audit gets harder as attempts multiply. When an agent tries 150 candidate paths before acting once, it leaves 149 abandoned branches. You need an exact record of what the winning attempt read, both to explain the decision to auditors and to give engineers something to debug.

The business impact of real-time data

Running directly on live data cuts costs, opens new revenue, and prevents losses.

Lower costs

Caches and replicas that exist only for performance add infrastructure cost and management work. Moving workloads to live operational data removes the need for those copies. Each application after the first also costs less, because it reuses the same live data foundation.

New revenue

Deciding in real time, while the customer is still engaged, makes these possible:

• Automated lending: Lenders can allow small businesses to apply for a loan in a couple of minutes and approve them automatically in one second.
• Retail: Retailers can offer a substitute product before the shopper abandons the cart.
• Dynamic pricing: Marketplaces can change prices as supply and demand move.

Work that used to wait for a scheduled batch job or a static report can run immediately, which also makes it a good fit for AI agents.

Fewer losses

Prevented losses are the easiest return to measure:

• Detecting and blocking fraudulent transactions before authorization.
• Preventing inventory overselling and unfulfillable orders.
• Enforcing strict risk and exposure limits in real time.

Where to start

Farkas gave practical advice: pick a stack that can handle these workloads today, and don't assume it will stay the best option forever. That advice also points to where to begin.

In most organizations, one workload already shows the problem: a cache added to work around slow queries, or two systems someone reconciles by hand so the account balances match. Find the use case where stale or conflicting data costs the most, and move that process to a live data layer.

Organizations are still deciding how much autonomy to give AI agents. When an agent gets permission to issue a refund or flag an order, it works from the same data and access permissions as real-time fraud detection and inventory reservation tools. Moving that workload to active data improves performance before any agent is involved, and the agents that come later start with the current state of the business.