Database Provisioning Is Now an AI Agent's Job

Originally published on DevToolHub.

When Neon's serverless Postgres platform hit general availability in 2024, roughly 30% of new databases on it were created by AI agents instead of humans. By the time Databricks acquired Neon in May 2025 — reportedly for about $1 billion — that number had passed 80%, and Databricks' January 2026 State of AI Agents report says it's still above that line. Database provisioning used to mean a ticket, a Terraform apply, and a wait. Now it's something an agent does mid-task, without asking anyone.

This isn't a vector-search story. It's a plumbing story. The part of the stack that decides how fast a database can appear, fork, and disappear again is being rebuilt around agents instead of people. That changes a few things about how you should design access to your own databases.

From 30% to 80%: Database Provisioning Is Now Automated

Databricks cited this shift as a direct reason for acquiring Neon. OLTP databases are a market built on tools designed decades before anything called an "agent" wrote a line of SQL. Per Databricks' 2026 State of AI Agents report, which draws on telemetry from over 20,000 organizations, 97% of database branches on the platform now get created through natural-language agent requests instead of a human running a CLI command. Multi-agent workflow usage on Databricks grew 327% between June and October 2025 alone.

That growth is why provisioning speed suddenly matters. A developer opening a ticket can tolerate a 10-minute wait for a new database. An agent mid-task cannot. It's spinning up an isolated environment to test a schema change, and it either gets a database in under a second or the whole workflow stalls.

Why Database Provisioning Had to Get Faster for Agents

Neon's pitch has always been instant, isolated Postgres instances instead of a shared staging database everyone fights over. Databricks CEO Ali Ghodsi put the agent version of that problem bluntly to TechCrunch: "Because these agents are super fast. They just spin up lots of databases, much faster than humans can, but you don't want to go bankrupt doing that." Copy-on-write branching lets them try a change against real production data and throw it away if it's wrong, without touching the primary environment.

That's a different requirement than the one traditional provisioning tools were built for. Terraform, CloudFormation, and RDS snapshots all assume a human is planning ahead. An agent making a database decision inside a single tool call needs infrastructure fast enough that provisioning stops being a step it has to plan around at all.

How Lakebase Handles Database Provisioning in Under 500ms

Databricks rebuilt Neon's internals under the name Lakebase. The architecture is why the speed claim holds up. It decouples compute from storage and moves storage onto object storage. Then it adds two components to make that fast enough for a database.

Safekeepers, built on the Paxos consensus algorithm, handle low-latency writes. Page servers compensate for object storage's latency by serving reads quickly, without losing transactional consistency.

The result, per Databricks' Data + AI Summit 2026 keynote: branch creation lands under 500 milliseconds, new-instance creation under a second. The platform handles 12 million database launches a day in production. A newer addition, Lakebase Search, adds hybrid vector and full-text retrieval with 32x index compression, and can index over a billion vectors — it now ships as lakebase_vector and lakebase_text extensions you install with a plain CREATE EXTENSION. That folds search into the same provisioning layer instead of bolting it on as a separate service.

[IMAGE: articles/images/2026-08-25-database-provisioning-ai-agents-diagram.png | alt: "database provisioning pipeline showing an AI agent request flowing through safekeepers and page servers to a new branch"]

Tiger Data's Agentic Postgres Takes a Different Approach

Neon isn't the only vendor rebuilding around this. Tiger Data — the company behind TimescaleDB — shipped Agentic Postgres on a storage layer it calls Fluid Storage. It's built for zero-copy forks of production data in seconds. An agent can spin up a full copy of production, benchmark a new index against it, and discard the fork without ever touching the live database.

Search is where Tiger Data diverges from Neon. Instead of leaning on pgvector alone, Agentic Postgres pairs pgvectorscale for higher-throughput vector indexing with a new pg_textsearch extension. That extension implements BM25 ranked keyword search, aimed squarely at hybrid retrieval for agent workflows. It also ships an MCP server, so an agent can provision and configure a database from a plain-language prompt instead of a schema migration script. Tiger Data has since opened a free tier for it, which makes it cheap to test the fork-per-agent pattern before committing.

Two well-funded companies independently reached the same conclusion. The bottleneck for agent-driven work isn't query speed. It's how fast you can hand an agent its own disposable copy of the database. That's a specific, testable claim, not a marketing line.

Where Database Provisioning Breaks: pgvector and Branching Limits

None of this is friction-free. pgvector runs entirely on CPU — there's no GPU offload. And the memory math gets unforgiving at scale: 50 million vectors at 768 dimensions is roughly 150GB of raw vector data alone, before the HNSW index built on top of it, which in practice can more than double the total footprint. Where the ceiling sits depends on your hardware and recall target, but if your agents run concurrent vector search over embedding sets in the tens of millions, memory and CPU — not provisioning speed — become the constraint.

Branching has a narrower limit too. Neon's branch-and-fork model was designed for development and CI workflows — a handful of long-lived branches per project. Fleet-scale agent workloads want the opposite pattern. They need hundreds of lightweight, ephemeral branches created and torn down per minute, each isolated to a single agent run. That's closer to per-request sandboxing than to a Git-style branch. It's not what Neon's original design, or most managed Postgres services, were built to sustain at volume.

⚠️ Important: if you're letting agents provision their own databases or branches, put a hard quota on branch count and lifetime per agent first. An agent stuck in a retry loop can create branches far faster than a human ever would. And "scale to zero" only helps your bill if something eventually tears the branch down.

What This Means for Your Database Access Patterns

There's a broader trend backing all of this. Native vector support is moving back into general-purpose relational databases instead of staying in dedicated vector stores. SQL Server 2025 ships a native VECTOR data type built into the core engine. It supports up to 1,998 dimensions, stores data in optimized binary, and pairs with DiskANN-based approximate nearest-neighbor indexes. Oracle's AI Database 26ai ships AI Vector Search as a built-in feature, not a bolt-on. RDS and Cloud SQL already lean on pgvector for the same job. Database provisioning and the vector search agents need are converging into the same box.

That has practical consequences. Stop treating "provision a database" as a privileged, human-gated action if agents are already doing it in your stack. Design the access boundary around the agent's identity and scope, not around a shared service account. Budget for cleanup, too — an agent that can create a branch in 500ms can also forget to delete ten of them. And if you're choosing where embeddings live, native vector support in Postgres now has real production backing at scale. That changes the calculus against standing up a separate vector database by default.

None of this requires a migration if you're already running PostgreSQL 18. Lakebase and Agentic Postgres are both Postgres underneath, so the SQL you write doesn't change. What changes is who issues the CREATE DATABASE call, and how fast they expect it back. The Model Context Protocol guide covers the layer actually issuing these provisioning requests. And if you're weighing where a given workload belongs at all, the breakdown of different database types is still the right starting point before assuming agent-driven Postgres fits everything.

Frequently Asked Questions

Q: Do I need to switch to Neon or Tiger Data to let AI agents provision databases?
A: No. Both are specific implementations of a broader shift toward fast branching and forking on top of Postgres. If your managed Postgres already supports quick snapshots or read replicas, you can build a scoped-down version of the same pattern. You just won't get sub-second provisioning without a storage layer built for it.

Q: Is pgvector no longer good enough for AI workloads?
A: It's fine for moderate scale. The CPU bottleneck shows up specifically at large vector counts with high concurrent query volume — most teams won't hit it. Test with your actual embedding count and query rate before assuming you need a different engine.

Q: What's the real risk of letting agents provision their own databases?
A: Runaway resource creation, not data loss. An agent in a retry loop can create branches or instances far faster than a human, so the fix is a hard quota on branch count and lifetime per agent identity, not a ban on the capability.

Q: Does this trend replace dedicated vector databases entirely?
A: Not entirely, but it removes the default reason to reach for one. When Postgres, SQL Server, and Oracle all ship native vector search, a standalone vector database has to justify itself on something beyond "it does vector search" — usually scale or a specific indexing algorithm you can't get natively yet.

Quick Summary

• Over 80% of databases provisioned on Neon are created by AI agents, up from roughly 30% at its 2024 GA, per Databricks
• Databricks' Lakebase architecture provisions new Postgres branches in under 500ms (new instances in under a second) using Paxos-based safekeepers and separate page servers, handling 12 million launches a day
• Tiger Data's Agentic Postgres takes a different route to the same problem: zero-copy forks on "Fluid Storage" plus pgvectorscale and a new BM25-based pg_textsearch extension
• pgvector is CPU-bound, and memory becomes the real ceiling in the tens of millions of vectors; Neon's original branching model wasn't built for hundreds of ephemeral agent branches per minute
• SQL Server 2025, Oracle AI Database 26ai, and RDS/Cloud SQL all now ship native vector search, pulling that workload back into general-purpose relational databases

If agents already touch your database layer, put a branch quota and a teardown policy in place before you give them database provisioning access — the infrastructure is fast enough now that the bottleneck is entirely on your side.