Skip to content

CONCEPT Cited by 1 source

Agent-provisioned database

Definition

An agent-provisioned database is a running, data-bearing database instance that is created on demand by an agent, on behalf of a human user, through an agent-provisioning orchestrator, without the user visiting the database vendor's dashboard, entering payment details, or provisioning infrastructure by hand. The database appears in the user's account at the provider as a first-class resource (not a delegated sub-identity or sandbox) and is addressable by its normal connection string; the agent holds the credentials via the orchestrator CLI and uses them to issue ordinary queries.

Specialises concepts/agent-provisioned-account to the database-resource tier: where the account concept covers identity + credential + billing provisioning, the agent-provisioned-database concept adds the substrate requirements that make a database a workable unit of agent-lifecycle rather than a long-lived operational asset.

Canonicalised by the 2026-04-29 Databricks + Stripe Projects launch:

"Agents can now get a production-ready Neon Postgres database in under 350ms, without any human interaction."

Substrate requirements

Not every database architecture can play the agent-provisioned- database role. The primitive structurally depends on three substrate properties, all named in the launch post:

  1. Sub-second provisioning. The database must be standable up fast enough that the agent session is not interrupted. The disclosed number is <350 ms for Neon Postgres on Lakebase through Stripe Projects. Traditional "provisioning-minutes" OLTP stores are disqualified — a 5-minute wait during agent scaffolding breaks the autonomy contract the agent-provisioning protocol targets.
  2. Scale-to-zero economics. Agents are expected to create databases speculatively — for a branch, a test, a prompt experiment — and abandon many of them. Pay-for-idle pricing turns each speculatively-created database into a lingering cost liability. Scale-to-zero makes ephemerality economically free.
  3. Compute-storage separation. The load-bearing architectural forcing function. Verbatim from the Databricks launch: "By decoupling compute from storage, agents can create, build, and tear down OLTP databases in seconds." Without the separation, creating a new database means allocating new storage (slow) and tearing one down means orphaning data (slow + potentially dangerous). With the separation, the compute lifecycle is per-request-cheap and the storage tier absorbs it as a cheap-clone / cheap-drop operation.

A fourth optional-but-valuable property:

  1. Copy-on-write branching. Enables agents to safely test changes against real production data state without risking the primary. From the launch post: "Using zero-copy cloning, agents can create isolated branches of production data in seconds."

Distinction from agent-provisioned-account

concepts/agent-provisioned-account covers the identity + credential + billing provisioning layer. An agent-provisioned-database is the next layer up — a concrete, stateful, running resource inside such an account.

Axis Agent-provisioned account Agent-provisioned database
Payload identity + API token + billing record running data-bearing system
Creation cost cheap (metadata rows) must be engineered cheap (compute spin-up + storage attach)
Teardown cost revoke token must be engineered cheap (compute kill + storage detach-or-drop)
Latency floor seconds-order (cold path) sub-second required for agent-autonomy
Substrate requirement identity store + billing ledger scale-to-zero + compute/storage separation
Typical use one per agent-user-provider triple many per agent session (branching, testing, ephemeral envs)
Prior art Cloudflare via Stripe Projects (2026-04-30) Databricks/Neon via Stripe Projects (2026-04-29)

The two compose: a Cloudflare-sibling provider could offer an agent-provisioned database inside an agent-provisioned account, with the account creation happening once and the database creation happening many times per session.

Distinction from developer-sandbox database

Developer sandbox databases (PlanetScale branches, Neon branches, Supabase preview environments) have the same substrate requirements but a different user-facing contract:

  • Developer sandbox: human dev creates + tears down, minutes-level latency acceptable, often tied to a CI or git branch.
  • Agent-provisioned database: agent creates + tears down, sub-second-level latency required, tied to an agent session or task.

The agent-provisioned-database primitive reuses the developer- sandbox substrate but adds the autonomy contract (no human detour) and the latency floor (<350 ms target).

Canonical use cases (from launch post)

From the Databricks launch, the post names three intended agent-operation modes for an agent-provisioned database:

  1. Safely test code. Agent makes code changes, points them at a branched copy of production data, runs the test suite, keeps or discards.
  2. Run migrations. Schema migration applied to a branch, validated against real data, promoted (or discarded) per a deploy-request-like flow.
  3. Experiment with prompts against live data states. Agent prompt/agent-logic iteration tested against a branch of production trace data (spiritual sibling to the patterns/policy-testing-via-database-branching pattern LangGuard canonicalised 2026-04-27, but now with the agent rather than a human governance team as the experimenter).

Trust + safety posture

The launch post does not disclose:

  • Spend-cap default for agent-initiated database creation through Stripe Projects.
  • Rate limits on per-account database-creation calls.
  • Fraud heuristics for catching churn-for-credential-harvesting abuse patterns.
  • Cleanup / TTL policy for orphaned agent-created databases.

These are load-bearing open questions at the cross-section of the agent-provisioning protocol and the scale-to-zero economic model — the same substrate property that makes the primitive viable (pay-for-actual-use) also makes it abusable (create-and-abandon churn has no natural dampening signal from the economic layer).

Relation to the agent-provisioning protocol

The agent-provisioned database is a resource class in the agent-provisioning protocol's catalog, alongside Cloudflare Registrar's domain resource class. The 2026-04-29 Databricks launch adds this class to the protocol coverage, validating the protocol's generalisation claim ("any platform with signed-in users can integrate") with a concrete second provider running a structurally different resource.

Open questions

  • What happens when a branch outlives the agent session? The agent may exit (context window exceeded, task timeout, crash); the branched database persists in the provider's account. Whether the protocol obligates the orchestrator to garbage-collect on agent exit, or the provider to TTL orphaned branches, or the user to clean up manually, is not yet standardised.
  • Is the <350 ms latency preserved under concurrent load? The number is presented as typical-case; whether the sub-second floor holds during a burst of agent-initiated provisions (dozens of branches per session × many-sessions-per-user × many-users-per-orchestrator) depends on the provider's burst-compute headroom and is not disclosed.
  • Does the agent see the database as addressable from its own runtime, or only via the orchestrator CLI? The launch post frames Stripe Projects as the credential custody layer; whether the agent connects to the returned connection string directly or through a proxied channel affects both latency and security posture.
  • Cross-provider composition. Can an agent create a Lakebase/Neon database via Stripe Projects and wire it into a Cloudflare Worker also provisioned via Stripe Projects, with both flowing through a single agent-provisioning session? The 2026-04-30 Cloudflare launch referenced cross-product wiring as a goal but did not specify cross-provider data-plane connection details.

Seen in

  • sources/2026-04-29-databricks-and-stripe-projects-infrastructure-built-for-agents — canonical introduction; Databricks joins Stripe Projects as launch-side provider of Neon Postgres databases as agent-provisioned resources. Introduces the <350 ms provisioning-time floor as the first wiki operational datum for agent-driven database creation and names scale-to-zero + compute-storage-separation + Postgres compatibility as the three substrate pillars that make the primitive viable. Implicitly pulls copy-on-write branching in as the fourth substrate property when the use case is "test code / run migrations / experiment with prompts against live data states".
Last updated · 438 distilled / 1,268 read