AI Agents Are Now Provisioning 80% of New Databases. The Review Process Didn't Scale With Them.

The number behind AI agents provisioning databases

In October 2023, 0.1% of new databases on Neon were created by an AI agent rather than a person. By October 2025, that number was 80%.

That figure comes from Databricks' own reporting, measured across more than 20,000 customer environments on Neon, the serverless Postgres platform Databricks acquired in early 2025. For database branches, the short-lived environments used for testing and feature work, the figure is 97%.

Two years is not a long runway for a governance model to catch up to a workflow change, and it shows. AI agents provisioning databases is now the default path, not the exception, on any platform built for it, and most of the process built to catch a bad schema change was written for a world where a person opened a pull request.

What counts as "agent-created" in that number is worth being precise about. A developer, or another agent, describes what is needed in natural language. An agent handles the rest: it calls a provisioning API, sets up the schema, configures access grants, and creates the branch. Sometimes none of that touches a console a human ever opens.

The adoption case is straightforward, which is why it happened this fast. Before branching databases, spinning up an isolated test environment meant a ticket to a platform or DBA team, often with a multi-hour or multi-day turnaround. An agent that can fork a copy of production in seconds removes an entire queue from the development loop. Teams did not adopt agent-provisioned databases because governance was an afterthought; they adopted it because the alternative was visibly slower, and the slowness was the kind that shows up in every sprint retro.

What agent-provisioned actually means, mechanically

This is not the same claim as "AI writes code now." Vibe-coding tools generating application logic have been common for a while, and most engineering orgs have some review process wrapped around that, even if it is thin. Database provisioning is a step further down the stack: an agent is not suggesting a change for a person to accept, it is calling the same API a human engineer would call, with the same effect on production-adjacent infrastructure.

The workflow looks like this in practice. An agent working on a feature needs a test environment, forks a branch off the production schema, applies a migration to that branch, runs its checks, and either merges the change back or discards the branch. Each of those four steps used to be a decision a person made deliberately, spaced out over a code review cycle. At agent speed, all four happen inside one conversational turn, sometimes repeated dozens of times an hour.

The branching itself is usually copy-on-write: a new branch does not duplicate the full dataset, it references the parent and only stores what changes from that point. That is what makes forking a multi-gigabyte production database a sub-second operation instead of a restore-from-backup job. It is also why the failure modes below are not toy problems confined to a sandbox. A branch shares storage lineage with production until it diverges, and the credentials issued for it are, by default, real database credentials, not a scoped-down simulation of one.

Failure mode one: schema drift from partial migrations

When a human-run migration fails halfway through, it usually fails inside a deploy pipeline with rollback semantics attached, or at least a person watching the terminal who stops and fixes it. When an agent-issued migration fails partway, the more common pattern is that the agent just retries, often with a different statement, layering a second incomplete change on top of the first.

The result is what database engineers call schema drift: the live database ends up in a state that matches neither the schema before the change nor the one the migration intended. Columns exist in production that never appear in any version-controlled migration file. Foreign keys reference tables a rollback already dropped. Grants outlive the objects they were scoped to.

None of this throws an obvious error at the moment it happens. It shows up later, as a query that fails against a field the agent assumed was still there, or as a migration that cannot run cleanly because the target schema does not match what the migration file expects. Enough teams have hit this that purpose-built validators, checking live schema against expected state before a query runs, have started showing up as open-source projects rather than internal scripts.

Failure mode two: orphaned branches and the credentials that outlive them

The 97% branch figure matters more than the 80% database figure, because branches are supposed to be disposable by design. An agent forks a copy of production, tests a change against it, and the branch is meant to be deleted once the test run ends.

In practice, deletion is exactly the kind of step that gets skipped. Either the agent's task was scoped as "make the change work," which does not include cleanup on a failure path, or the branch survives a conversation that simply ends without a closing action. Multiply that by however many branches a fast-moving team spins up in a week, and the storage bill is the visible symptom.

Coverage of Databricks' broader agent adoption report frames this as a governance bottleneck rather than an adoption problem: usage is running well ahead of the controls built for it, across more than database provisioning specifically.

Why pull-request review does not cover this

Most engineering organisations built their review muscle around one artefact: the pull request. Migrations that ship through the same pipeline as application code inherit the same review, roughly, because a migration file sits in the same repository and goes through the same merge gate.

Agent-issued DDL against a provisioning API skips that path entirely. There is no file to open a pull request against, because the change was never committed as one. This is not a story about engineers being careless with schema changes. It is that a second, faster route to the database opened up next to the one the review process was built to watch, and the review process was never pointed at the new route.

There is a precedent for this shape of problem, and it points at how long it can take to close a gap like this without deliberate effort. Infrastructure-as-code tools went through the same transition a decade earlier: Terraform and its peers let engineers describe infrastructure declaratively, and state drift, where the live infrastructure no longer matches the declared configuration, became its own well-known failure category, with its own tooling built specifically to detect it. That tooling did not appear because Terraform was badly designed. It appeared because the industry needed a few years of production incidents before drift detection became a checklist item rather than a nice-to-have. Database provisioning is earlier in that same curve.

Four guardrails that keep the speed without losing control

None of these require slowing agents back down to human pace. They require deciding, in advance, what an agent is allowed to do unsupervised and what triggers a check.

The third guardrail is the cheapest to implement and closes two problems at once. A scoped credential, created per session and tied to a single branch, cannot become a standing security exposure, because it stops working the moment its branch expires. A shared service account with broad grants cannot make that same guarantee, no matter how good the branch cleanup is.

-- One role per agent session, scoped to a single branch, with a hard expiry.
CREATE ROLE agent_session_8f21
  WITH LOGIN PASSWORD :'session_secret'
  VALID UNTIL :'branch_expiry';

GRANT CONNECT ON DATABASE app_branch_8f21 TO agent_session_8f21;
GRANT USAGE, CREATE ON SCHEMA public TO agent_session_8f21;

-- Deliberately no grants beyond this branch's schema,
-- and no membership in any broader role.

The fourth guardrail is the one that actually addresses the review gap. It does not route every agent write through a human, which would erase the speed advantage that made agent-provisioned databases worth adopting. It routes DDL, specifically statements that change the shape of the database rather than its contents, through a check that a person or a validation service actually sees before it lands.

The distinction between DDL and ordinary writes is doing real work here. An agent inserting, updating or deleting rows within an existing schema is operating inside boundaries a person already approved when that schema was designed. An agent adding a column, dropping a constraint or changing a grant is redrawing those boundaries. Treating both as the same category of action, either by gating everything or by gating nothing, is what leaves teams choosing between agent speed and any review at all. Splitting the two lets a team keep one and add back the other.

What to measure instead of provisioning volume

The 80% figure is a velocity metric. It says nothing about how many of those databases still exist, whether their credentials are still active, or whether their live schema still matches anything checked into version control. A team that reports on provisioning volume alone is measuring the part of this shift that was never the risk.

A more useful dashboard tracks three things: the branch TTL compliance rate, meaning what share of branches actually expired on schedule rather than being manually kept alive or silently abandoned; the count of DDL statements issued outside the versioned migration path in a given period; and the number of non-human credentials older than the branch they were scoped to. None of those numbers existed as a reporting category two years ago, because the workflow they describe barely existed either.

Provisioning speed is not the part of this that needs fixing. Most database governance was written for a world where every schema change came from someone who would eventually get paged if it broke something. That assumption is the part that stopped being true first.