Every DBA has seen it at least once. You are looking at the production database and something feels wrong. CPU is climbing. Logical reads are surging. One or two sessions are consuming far more resources than everything else combined.

You drill down into the SQL.

The query is unfamiliar. It joins more tables than you would expect, sometimes even joining the same table multiple times. The execution plan is complex, the logical reads enormous.

The first question is always the same: where did this query come from?

Often the answer is simple. A new application feature has been released. Somewhere inside it is a query that looked perfectly reasonable in testing. Run once or twice, it behaved well enough.

Production tells a different story.

Now the query is executed repeatedly. Sometimes concurrently. Sometimes triggered by user behaviour the test harness never simulated. Occasionally the query runs long enough for the application to time out, so the user refreshes the page, launching another execution while the first one is still running.

What looked harmless in isolation becomes dangerous when multiplied across real workloads.

But a DBA usually has one advantage: you can usually find the human behind the query.

Someone wanted to know something. Once you understand that intent, the workload can usually be controlled. Run it less often. Move it elsewhere. Rewrite it entirely.

Operational databases survive because their workloads are ultimately bounded by human intent. AI agents change this equation in a subtle but important way.

When the Database Becomes Part of the Reasoning Process

Traditional enterprise applications interact with databases in predictable ways.

An application developer writes the query. It is tested, reviewed, and eventually deployed. Over time the database develops a recognisable workload pattern. DBAs learn those patterns, optimise them, and build operational safeguards around them.

Even complex systems ultimately follow this model. A user action triggers application logic, which triggers a known set of database queries.

AI agents behave differently.

Instead of executing a predefined query pattern, an agent may generate queries dynamically as part of a reasoning process. It retrieves data, evaluates the result, refines the question… and queries again.

In other words, the database is no longer simply answering a question. It becomes part of the mechanism the system uses to figure out the answer.

This subtle shift has an important consequence.

Applications constrain database workloads.

Agents amplify them.

The Amplification Effect

A traditional application might translate a single user action into one or two database queries.

An agent may translate the same request into many.

The agent retrieves information, evaluates it, and then decides what to ask next. It may retry a query with different parameters, join additional tables, or explore alternative paths through the data.

Some systems do this only once or twice. More autonomous agents may repeat the process multiple times in a reasoning loop.

From the database’s perspective, a single human question can now generate many queries. In simple retrieval pipelines this may only be a handful. In more autonomous reasoning systems it can grow to dozens — sometimes even hundreds — as the agent explores the data.

Multiply that pattern across thousands of employees interacting with AI systems, and the database workload begins to look very different from the one the system was originally designed to support.

This is not necessarily a flaw. It is simply how exploratory systems behave. But it does change the shape of the workload interacting with production systems.

Why Traditional Controls Are Not Enough

Experienced DBAs will recognise that production databases already include many mechanisms designed to control runaway workloads.

Connection limits, query governors, resource groups, and timeouts exist precisely because poorly behaved queries can destabilise shared systems.

These controls work well when applications generate predictable query patterns.

What they are less suited to is a workload whose shape is not known in advance.

Agentic systems can generate new queries dynamically, retry failed steps, or explore alternative reasoning paths. The individual queries may not be problematic on their own. The challenge is the emergent behaviour that appears when many such queries interact with a production workload.

The result is a new class of operational uncertainty. In practice this can manifest as unexpected infrastructure consumption, runaway query costs in cloud databases, or production incidents triggered by exploratory workloads interacting badly with operational traffic.

When a traditional query misbehaves, a DBA can usually trace it back to a specific application feature or report. With agentic systems, the activity observed in the database may simply be a side effect of an evolving reasoning process.

Understanding why a query is running becomes much harder.

Enterprise Architectures Will Evolve

For this reason, the architecture implied by many early AI demonstrations is unlikely to survive unchanged in large enterprise environments.

Those demonstrations often show AI agents querying operational databases directly. For simple scenarios, that approach works well enough.

At scale, however, exploratory workloads interacting directly with systems of record create operational and economic pressures that are difficult to manage.

The likely response is architectural evolution.

Instead of allowing agents to query operational systems directly, enterprises will increasingly introduce intermediate layers designed to absorb exploratory behaviour. These layers might include analytical replicas, semantic data services, curated retrieval surfaces, vector indexes, materialised views, or other forms of controlled query infrastructure.

What matters is not the specific technology. It is the architectural separation.

Systems of record remain the authoritative source of enterprise data. But the exploratory behaviour of AI agents will increasingly occur one step removed from those systems.

Until architectures evolve to contain that behaviour, many enterprise AI initiatives will struggle to deliver the level of return on investment that early demonstrations appear to promise.

Not because the models fail, but because the surrounding architecture has not yet caught up with how those models actually behave.

This article is part of the Databases in the Age of AI series.

A bank executive opens a fraud dashboard in Microsoft Power BI.

Losses by region, chargeback ratios, transaction velocity trends and a heatmap of anomalous activity. The numbers refresh within minutes. Data flows out of the system of record, is reshaped and aggregated, then presented for interpretation.

This is contemporary analytics: fast and operationally impressive. But it remains interpretive. It explains what is happening, while intervention occurs elsewhere – inside a fraud model embedded in the execution path, deciding in milliseconds whether money moves or an account is frozen.

Reporting systems describe what has already occurred. Even when refreshed every few minutes, they are retrospective. Inference systems are anticipatory. They evaluate the present in order to shape what happens next.

For two decades, enterprise data platforms were built around a deliberate separation between systems of record and analytical platforms. The system of record handled revenue-generating transactions; analytics operated on copies refreshed hourly or even every few minutes. Latency narrowed, but the boundary remained.

AI systems do not consume summaries, however fresh. They make decisions inside the transaction itself. A real-time fraud model does not want a recently refreshed extract; it requires the authoritative state of the business at the moment of decision. When automation replaces interpretation, data freshness becomes a decision integrity requirement. That shift changes the role of the database entirely.

Snapshots ≠ State

The difference is not batch versus real time. It is snapshot versus canonical state.

A snapshot is a materialised representation of state at a prior point in time – even if that point is only moments earlier. It may be refreshed frequently or continuously streamed, but it remains a copy. The system of record contains the canonical state of the enterprise – balances, limits, flags and relationships – reflecting the legal and financial truth when a transaction commits.

In fraud detection, that distinction is decisive. A dashboard can tolerate slight delay because its purpose is explanation. A model embedded in the execution path cannot. It must evaluate current balance, velocity and account status, not a recently materialised representation.

For years, we increased the distance between analytics and the system of record to protect transactional stability. That separation reduced risk in a world where insight followed action.

Automation reverses that order. Insight now precedes action. Once decisions are automated, the gap between a copy of the data and the authoritative source becomes consequential.

When Almost Right Is Still Wrong

If a fraud dashboard is slightly stale, an analyst may adjust a threshold next week. When a fraud model evaluates incomplete or delayed state, the error is executed immediately and repeated at scale.

False declines can lock customers out within minutes. False approvals can leak substantial losses before discrepancies surface in reporting. Automation compresses time and amplifies mistakes because there is no interpretive buffer.

Real-time intervention is inevitable. Competitive pressure and regulatory scrutiny demand it. But once decisions are automated, tolerance for architectural distance shrinks. A delay harmless in reporting can be material in a decision stream. A dataset “close enough” for analytics may be insufficient for automated intervention.

The risk is not that dashboards are wrong; it is that forward-looking systems may act on something almost right.

Databases in the Age of Intervention

When fraud detection becomes automated intervention rather than retrospective analysis, the requirements on the data platform change. Freshness is defined at the moment of decision, not by refresh intervals.

Replication patterns take on new significance. Asynchronous copies and downstream materialisations were designed to protect the system of record. They optimise scale and isolation, but every layer introduces potential lag or divergence. For reporting, that trade-off is acceptable. For automated decisions in revenue-generating workflows, it becomes risk.

Workload separation also looks different. When analytics is retrospective, distance protects performance. When inference is embedded in operational workflows, proximity to live transactional state matters. The challenge is enabling safe, predictable access without compromising correctness.

Fraud detection is simply the clearest example. Dynamic pricing, credit approvals, supply chain routing and clinical triage all follow the same pattern. The model is not generating a report about what happened; it is evaluating the present to influence what happens next.

For decades, enterprise architecture assumed intelligence followed events. As AI systems become anticipatory and automated, intelligence precedes action. The database is no longer simply the foundation of record-keeping.

It becomes part of how the future is decided – whether we are comfortable with that or not.

This article is part of the Databases in the Age of AI series.

I have a habit of becoming interested in technology trends only once they collide with reality. Flash memory wasn’t interesting to me because it was new – it was interesting because it broke long-held assumptions about how databases behaved under load.

Cloud computing wasn’t interesting to me because infrastructure became someone else’s problem. It became interesting when database owners started making uncomfortable compromises just to get revenue-affecting systems to run acceptably in the cloud. Compute was routinely overprovisioned to compensate for storage performance, leading to large bills for resources that were mostly idle. At the same time, “modernisation” began to feel less like an architectural necessity and more like a convenient justification for expensive consultancy services.

And now, just when I thought flashdba had nothing left to say, AI is following the same path.

We’ve Seen This Movie Before

For the last couple of years, most of the attention has been on training. Bigger models, more parameters, more GPUs, massive share prices. That focus made sense because training is visible, centralised and easy to reason about in isolation. But as inferencing starts to move up into the enterprise, something changes.

In the enterprise, inferencing stops being an interesting AI capability and starts becoming part of real business workflows. It gets embedded into customer interactions, operational decisions and automated processes that run continuously, not just when someone pastes a prompt into a chat window. At that point, the constraints change dramatically.

Enterprise inferencing is no longer about what a model knows. It is about what the business knows right now. And that is where things begin to feel very familiar to anyone responsible for systems of record.

Because once inferencing depends on real-time access to authoritative operational data, the centre of gravity shifts away from models and back towards databases. Latency matters. Consistency matters. Concurrency matters. Security boundaries matter. Above all, correctness matters.

This is the point at which inferencing stops looking like an AI problem and starts looking like what it actually is: a database problem, wearing an AI costume.

Inferencing Changes Once It Becomes Operational

While inferencing remains something that sits at the edge of the enterprise, its demands are relatively modest: a delayed response is tolerable… slightly stale data is acceptable. If an answer is occasionally wrong, the consequences are usually limited to a poor user experience rather than a failed business process.

That changes quickly once inferencing becomes operational. When it is embedded directly into business workflows, inferencing is no longer advisory… it becomes participatory. It influences decisions, triggers actions and – increasingly – operates in the same execution path as the systems of record themselves. At that point, inferencing stops consuming convenient snapshots of data and starts demanding access to live context data.

What is Live Context?

By live context, I don’t mean training data, feature stores or yesterday’s replica. I mean current, authoritative operational data, accessed at the point a decision is being made. Data that reflects what is happening in the business right now, not what was true at some earlier point in time. This context is usually scoped to a specific customer, transaction or event and must be retrieved under the same consistency, security and governance constraints as the underlying system of record. In other words, a relational database. Your relational database.

Live Context gravitates towards RDBMS systems of record. It does not appear spontaneously – it is created at the moment a business state changes: when an order is placed, a payment is authorised, an entitlement is updated or a limit is breached, that change becomes real only when the transaction is committed to the RDBMS. Until then, it is provisional.

Analytical platforms can consume that state later, but they do not create it. Feature stores, caches and replicas can approximate it, but they do so after the fact. The only place where the current state of the business definitively exists is inside the operational production databases that process and commit transactions.

As inferencing becomes dependent on live context, it is therefore pulled towards those databases. Not because they are designed for AI workloads, and certainly not because this is desirable, but because they are the source of truth. If an inference is expected to reflect what is true right now, it must, in some form, depend on the same data paths that make the business run.

This is where the tension becomes unavoidable.

Inferencing Is Now A Database Problem

Once inferencing becomes dependent on live context, it inherits the constraints of the systems that provide that context. Performance, concurrency, availability, security and correctness are no longer secondary considerations. They become defining characteristics of whether inferencing can be trusted to operate inside business-critical workflows at all.

This is why enterprise AI initiatives are unlikely to succeed or fail based on model accuracy alone. They will succeed or fail based on how well inferencing workloads coexist with production databases that were never designed, built or costed with AI in mind. At that point, inferencing stops being an AI problem to be delegated elsewhere and becomes a database concern that must be understood, designed for and owned accordingly.

This article is part of the Databases in the Age of AI series.