Agentic Database Changes Need More Than Replay Checks

An agentic database is a database, or a layer around one, that observes its own behaviour, proposes changes such as new indexes or rewritten queries, and in some designs applies them without a human. We think the idea is right about the problem and too optimistic about how to prove a change is safe.

The common proposal is an autonomy ladder. The agent acts alone when it can prove a change correct, proposes when the outcome is uncertain, and asks when it lacks business context.

In this post we cover the case for an agentic database, what fork-and-replay verification proves, six production effects it misses, why the reviewable change is the right unit of trust, and where unattended action is reasonable.

The Case for an Agentic Database Is Strong

Databases are still the most hand-operated part of most stacks. Application deploys are automated end to end, while index tuning, vacuum problems and slow-query fixes still wait for a person to notice and act.

A database that already has the telemetry to see a slow query, a growing table or a vacuum falling behind could do more than wait for someone to run EXPLAIN. We agree with that argument, and with the idea that autonomy should be granted in steps rather than all at once.

The weak point is the top rung. For the agent to act alone, the system has to prove the change safe, and the usual proposal for that proof is fork-and-replay, cloning the database, applying the change and replaying recent production traffic to compare results.

What Fork-and-Replay Verification Actually Proves

Replay demonstrates answer equivalence. For the queries in the recorded window, on a copy of the data, the change produced the same results, and perhaps produced them faster.

That is a useful test, and we would run it on every proposed change. The trouble is that it gets read as proof of production safety, which is a much larger claim.

A fork is quiet. It has no competing transactions, no replicas to feed, no warm cache to disturb and usually no disk pressure, and production failures from schema and index changes tend to come from exactly those things.

Six Production Effects Replay Verification Misses

We see six effects that a replay on a fork cannot observe, each of which can turn a change that is correct in the narrow sense into a production incident.

1. Lock Waits and Lock Queues

Even the gentler options, such as CREATE INDEX CONCURRENTLY, take time and locks on a busy primary. The PostgreSQL documentation for CREATE INDEX says that with the concurrent option "PostgreSQL must perform two scans of the table, and in addition it must wait for all existing transactions that could potentially modify or use the index to terminate."

On a fork with no long transactions that wait never happens. On production, a long report or a stuck session can hold it open, and other operations that need stronger locks queue behind it, a pattern we describe in lock queues behind a metadata-only ALTER.

2. Plan Changes on Queries Outside the Sample

A new index can make the target query faster and change the plan the optimiser picks for other queries too. If those queries were not in the replay window, the regression stays invisible until production traffic hits it, which we cover in our guide to PostgreSQL query plan changes.

A partial guard is to capture plans for the most frequent and most expensive queries before and after the change, not only for the query the agent was trying to fix. Any query whose plan changed belongs in the evidence attached to the proposal.

3. Write Overhead From New Indexes

Indexes speed up reads and slow down writes, because every insert, update and delete must maintain them. The PostgreSQL introduction to indexes warns that "indexes also add overhead to the database system as a whole, so they should be used sensibly." A replay weighted towards reads can miss the cost on a write-heavy path entirely.

4. Cold Caches and Buffer Churn

A fresh fork starts with a different cache state from a primary that has been serving traffic for weeks. Building an index or running a large rewrite on production can push useful pages out of memory, so timings measured on the fork do not carry over.

The effect is usually temporary, but it lands on every query that depended on those pages, not only on the ones the change was meant to help, and that is exactly the kind of side effect a root cause analysis later struggles to connect back to the change.

5. Replication Lag From Write Volume

Index builds and rewrites generate write-ahead log that replicas must apply. A change that finishes quickly on a standalone fork can leave replicas behind on production, breaking read-after-write behaviour for applications that read from them.

6. Disk Headroom on the Real Volume

Thin clones share storage cleverly, so they rarely reveal how much space a large index build needs. On a production volume that is already close to full, the build itself can be the thing that fills it.

Some of these can be tested before production. A fork can be loaded with concurrent writes, given a realistic cache warm-up and placed on storage sized like the real volume. Each step narrows the gap, but each also makes verification slower and costlier, which removes much of the speed that justified acting alone in the first place.

The rest can only be watched. Lock waits, replica lag and disk use are best handled by applying the change in a chosen window, watching those signals as it runs, and having a rollback ready if any of them drift.

None of these effects means the change was wrong. It means correctness and safety are different properties, and a proof of the first says little about the second.

The Reviewable Change Is the Unit of Trust

If the act-alone rung is narrower than hoped, the benefit has to come from making the propose rung fast. We think the answer is to focus on the change itself rather than the permission boundary, and to make each change easy to review.

• It is a diff that shows exactly what will change.
• It carries a tested rollback, not just a forward plan.
• It attaches the evidence, including query plans, replay results and the metrics that prompted it.

Packaged that way, review takes minutes rather than an investigation, and the change can go through the same migration pipeline and deployment windows as any other. Database platforms already work like this. PlanetScale's documentation describes deploy requests as an integral part of its workflow, with review, deployment and revert steps for schema changes.

Fully automatic tuning has a harder history. Andy Pavlo's own biography notes that OtterTune, the database tuning start-up he co-founded, ran from 2020 to 2024 before it "died an untimely death." We draw no conclusion about why from that alone, but it is a reminder that unattended changes to production databases are a hard sell.

The same principle applies to any agent near production. Investigation can be made safe by keeping production credentials read-only and logging every query, so the agent can look widely while every change still passes through a person. We make the broader case in automated root cause analysis without AI write access.

Where Unattended Action Is Reasonable

We do not think the act-alone rung should be empty. Some change classes are low-risk, easy to undo and well understood, such as refreshing planner statistics or cancelling a query that has run past an agreed limit.

Autonomy for anything larger should be earned per change class. If an agent proposes the same kind of change many times, engineers approve it every time, and production metrics stay healthy afterwards, that class can move to unattended action with automatic rollback if replication lag, error rates or latency drift.

A written record of those approvals matters as much as the approvals themselves, a point we expand on in audit trails for AI infrastructure changes.

Propose Agentic Database Changes by Default

We would start every agentic database programme with propose as the default rung. Make each change a reviewable diff with evidence and a rollback, run replay as one test among several, and promote individual change classes to unattended action only after a track record exists.

That keeps the speed of an agent and the judgement of a person, and it is the split Operate is built around. Its built-in agents read production through read-only adapters and can't commit, open pull requests, merge, or deploy, and any fix arrives as a patch file an engineer reviews and applies.