Agentic databases aren't agentic.

Why the fuck is nobody letting the database act?

TigerData gives agents Postgres. GibsonAI killed its “AI backend engineer” and rebranded to MemoriLabs: memory for other people’s agents.

Useful? Yes.

Agentic? No.

OpenAI defines agents as systems that “independently accomplish tasks on your behalf.”

Everything the database companies sell inverts that sentence. The database is not the system accomplishing tasks, it is what the tasks get accomplished on. A database for agents, infrastructure for agents, memory for agents. The workbench, not the worker.

Oracle’s database does act, on its own knobs. Indexes, plans, caches. Agentic about the machinery, passive about your application. That is the line. The moment a change would cross it and touch what the application means, a rule, a schema, a fact, every database on the market goes silent and waits for you.

BUT the VALUE is in the actor, not the enabler.

PayPal’s founders built money for the hot platform of 1999: beaming cash between PalmPilots. Sending money over email was the demo, a boring hack on a rail that was already old. The demo ate the company.

Agents are the PalmPilot. The database is email.

Everyone is putting databases underneath agents. Nobody is putting agency inside the database.

Meanwhile, the database itself watches checkout slow down. It sees the same order land twice. It watches stock go negative.

It stores the evidence and waits.

Because we are scared. Nobody has the balls to ship software that does surgery on the heart of your application, the database, unasked.

But now we can, thanks to AI. So somebody should.

Your IDE writes code without you. Your CRM drafts emails. Your CI ships to production without asking. The system closest to the data, the one that sees every query, stores every fact, and remembers every change, still does nothing with what it learns. You pay people to notice what your database already knows.

Every app that matters stores its state in a database. Let that database improve the application on top of it, and the value reaches performance, reliability, business logic, data quality, schemas, and eventually analytics.

The work is hard, and the incumbents cannot want it: they sell compute, and an agent that touches meaning owns the blast radius. That leaves the valuable half of the category vacant. And the opportunity is larger than the database itself: once the database starts acting, it begins consuming the jobs, tickets, and tools built to compensate for its passivity.

Here is what an actually agentic database would have done last night.

What your database should have fixed before breakfast

At 2:14 a.m., checkout slowed to a crawl.

Every order request hit the same inventory join. As the catalog had grown, the query had tipped into a full scan.

The database created a covering index on a fork, replayed the last hour of production traffic against it, verified that every answer stayed identical, and deployed.

Checkout recovered. Nobody woke up.

A few minutes later, it found duplicate orders.

Payment retries were hitting a fragile “check, then insert” path. Under enough load, two requests occasionally slipped through together.

The database cleaned the duplicates on a fork and prepared the permanent fix as a pair: a unique constraint on its side and a pull request against the application.

Then stock went negative.

It only happened when two people bought the final item at almost exactly the same moment.

This time, the database stopped.

Fixing the race meant changing how checkout behaves. So it prepared an atomic reservation transaction, replayed the concurrent writes against a fork, attached the results, and asked.

By breakfast, you would find:

18 reversible changes made. Fifteen too boring to mention.
Checkout bottleneck removed.
Duplicate orders cleaned; permanent fix ready to merge.
One checkout rule waiting for your decision.

No empty chat window. No ticket.

Nobody typed “please inspect my database for possible improvements.” That product exists, it is autocomplete with office hours.

This is a faster application, a changelog, and one decision waiting in the morning.

That is the whole autonomy model: act where correctness can be proven, propose where behavior changes, ask where meaning begins.

The database is the safest place to let an agent act

For years, autonomous databases stopped below the line: indexes, query plans, caching, partitioning, replicas. That was not the natural boundary of the category, it was the boundary of the technology. Oracle got there with telemetry and a bounded menu of responses. OtterTune tried to build a whole company down there and couldn’t make it stick; it shut down in 2024. The real category starts above the line. Language models just moved the boundary.

The fear, never let a machine touch production data, misses where agents actually started. Agents ate code first because code had Git: branch, diff, review, merge, revert. Databases have spent fifty years building better protection than that: transactions, constraints, write-ahead logs, versioned migrations, audit trails, and a fifty-year-old undo button. All of it exists because imperfect actors already touch production data.

I have met humans. The scariest place to put an agent is the place best prepared to contain one.

I called the discipline Data as Code back in 2021: data changes versioned, tested, reviewed, and deployed, never invisible manual operations. This is Data as Code after the database starts writing its own changes.

It discovers the rules your application forgot to enforce. A refund that can exceed its original charge reveals a missing check. Six services validating the same field six different ways reveal a rule that belongs closer to the writes. (Yes, rules in the database, the oldest fight in data engineering. The difference this time: the database can read the application’s side of the contract.) The database prepares the constraint, a coding agent updates the application, and both sides run against the same fork before they merge. Wild in 2023. Plumbing now: Tiger and Neon fork entire databases in seconds and PlanetScale runs schema changes as deploy requests.

It evolves the schema from how the application is actually used. The same six fields have lived inside a JSON blob for eight months. Promote them to typed columns. Every service calculates the same value before writing. Make it part of the schema. Two customer tables have drifted toward 94% overlap. Trace the dependencies, prepare the merge, and ask. The schema stops being a snapshot of what somebody understood three years ago.

It deletes what humans are afraid to delete. legacy_orders has not been queried in a year. A view lost its final user six months ago. Three columns survive because nobody knows whether removing them is safe. The database sees every query, dependency, read, and write. It archives the objects to a fork, removes them from production, and keeps the revert one click away.

It reaches outside itself before touching meaning. It finds Lipzig in a city column. Maybe someone misspelled Leipzig. Maybe Lipzig is a company, a brand, or a place the model has never heard of. So it checks the CRM, validates the postal code, compares the invoicing address, and attaches the evidence first:

Proposed Lipzig → Leipzig
CRM record 4711 agrees.
Postal code agrees.
Original preserved.
Revert available.

For fifty years, data flowed into the passive database. This one reaches outward and pulls better facts toward itself.

The moat is permission

One more way to fail: become the agent that never shuts up. Most agent products promise autonomy and deliver fifty suggestions, twenty pull requests, and a new dashboard to babysit, the work, automated into a second job. A good agent reduces the number of times you have to speak to it.

The database begins like a new hire. At first, it proposes almost everything. You approve the safe changes, reject the strange ones, and teach it what your company means by “customer,” “duplicate,” “stale,” and “wrong.” You connect the CRM, and some APIs. Then it earns autonomy one class of change at a time. It graduates from suggesting indexes to deploying them. Stable JSON fields get promoted automatically after ninety days. Finance tables remain proposal-only forever.

Every accepted change expands its operating range. Every rejection sharpens the boundary. Every successful revert proves what it can survive.

A competitor can copy the features. It cannot copy the history of what this organization has learned to trust.

Trust becomes training data.

The agentic database’s creative destruction

The features are the product. The destruction is the business.

Every workflow the database absorbs expands the market. Every absorbed workflow gives it more context about the application. And every additional action strengthens the learned trust a competitor cannot simply copy.

It starts consuming the stack built around the fact that databases never acted.

The first casualty is the ticket queue. Today, the database watches checkout slow down, duplicate orders appear, and the same race condition fire again, then waits for a developer to notice, an SRE to investigate, a DBA to intervene, and an application team to coordinate the fix. The agentic database collapses that queue. Not all DevOps work: the database-shaped toil created because the system closest to the problem never initiates anything.

Then the bolt-on policing layer starts shrinking. Observability and data-quality products stand outside the database and report, after the fact, that something went wrong. The agentic database was present when the write happened. It knows the source, the rule, the dependencies, and the history. Quality, lineage, and governance do not disappear. They become generated evidence and operating policy instead of separate human-maintained worlds reconstructing events later. OpenAI already runs the pattern internally, by their own account, Codex agents live inside their data platform, catch schema drift, and draft the fixes. A layer above the database, bolted on from outside.

Then there is dbt. I spent years as the product owner of a BI and data platform used by roughly 700 people. I lived inside the queue between “someone needs a column” and “the column exists.” The database saw every analyst repeat the same join, calculate price × quantity by hand, and dig the same values out of the same JSON blob. The query optimizer already decides how to answer a query across milliseconds; now the database can decide what to preserve across months. It writes the model, tests it, documents it, materializes it where useful, and retires it when nobody asks the question anymore. Analytics survives. SQL survives. Warehouses survive where columnar compute and workload isolation matter. dbt may even run underneath. It stops being the work.

Finally, the warehouse project becomes optional. Large organizations may still need separate analytical compute. Physics remains physics. But smaller companies get a maintained analytical layer without first assembling ingestion, orchestration, modeling, quality, catalog, BI, and the team required to hold it all together. The database starts eating the jobs, tickets, and tools created to compensate for the fact that it stored everything, understood nothing, and never acted.

I checked. The pieces exist; the tech is ready. The agentic database does not.

I like this idea enough that I am mildly annoyed I am writing about it instead of building it.

Please beat me to it.