When the database's newest user is an agent

Next month, two hundred people from the sales team fly to Chicago for the annual kickoff. The company books every trip through AI agents, one per traveller. Each agent searches fares, tries options, waits for approvals and books. Some will crash. Some will retry. Several will reach for the last hotel room at the same moment.

In part 1, one booking agent crashed after the airline confirmed, before saving the result, and on restart it risked buying a second ticket. Now there are two hundred of them, all writing to the same systems.

None of them will ask the database team before it starts. Yet each one needs access and limits before its first booking.

A new kind of database user

Database administration has always covered the same ground. Who gets access, which schema changes go in, how much capacity to plan, how to back up and recover. For a long time, a database administrator, or DBA, owned most of those calls.

To be fair, much of that was automated long before agents. Managed cloud databases took over backups and patching. Teams could already create databases from scripts they review; AWS launched CloudFormation in 2011. Keeping stored data separate from the machines that run queries isn’t new either. AWS described Aurora’s decoupled compute and storage in 2016, and Snowflake’s 2016 paper separates query compute from shared storage.

What agents change isn’t that automation exists. It’s the volume and variety of requests, and how few of them a person will ever see. And agents reach the database in two ways. Some use it: the booking agents, changing shared bookings at once. Others change the software around it: coding agents that build and fix the travel tool itself, and create databases to test their changes on.

Two vendor figures show how much database creation agents already do on some platforms. Both are self-reported:

• Databricks said in May 2025 that internal telemetry showed over 80% of databases provisioned on Neon were created by AI agents.
• Supabase said in October 2026 that 70% of its new databases were created by agents or AI-driven tools.

They come from different platforms. Neither linked announcement explains how it was measured, and the figures aren’t directly comparable. And they count databases created, not databases that stay in use or hold agent memory. They’re about the second kind of agent, the ones building software. What they show is a new kind of user, one that creates databases without filing a ticket and waiting.

The picture I use is a kitchen. A database used to be a restaurant kitchen: a few experienced cooks, careful rules, someone in charge who knows who’s at which station. Agents turn it into a cooking school. Hundreds of students each want a practice kitchen right now. They make messes and need a reset button. Someone still has to keep them away from the knife drawer, and with hundreds of kitchens, the platform has to enforce that rule in every one.

Here’s what that asks of the database:

Agents…	What helps
are many	Databases created on demand, cheaply
work in bursts	Compute that scales up, and down to zero when idle
experiment and make mistakes	Cheap, isolated branches and restore points
throw work away	Scratch copies that expire, with only the records kept
can be fooled	Authority scoped to the task, enforced outside the model
spend without noticing	Limits and quotas the platform enforces
must answer for what they did	A record of who asked, what the agent did, and what happened

Not every team needs every row. A few agents sharing one database need less than a platform where agents create thousands. What the rows share is a move from “a person checks” to “the platform enforces.”

The DBA doesn’t disappear. The repeatable parts become policy the platform applies to every request. People still own data modelling, recovery design, performance trade-offs and the exceptions.

Two jobs that pull apart

Put part 1’s split, scratch and records, together with this new kind of user, and the data layer has two jobs that pull in opposite directions.

Disposable workspace

the practice kitchen

Fast to create

Safe to break

Cheap to throw away

Expires with the task

save what must be kept, before acting on it → ↓

Durable record

the dining room

What the agent was shown

What it did

What happened, and why

Kept after the workspace is gone

The workspace is where a coding agent tries a change before it’s real: a new feature, a schema change, a data fix. The record keeps the approval and the request number before booking starts, then the outcome once the airline confirms. It’s what you’ll need when someone asks, “why did it book that?”

Why branching alone isn’t enough

Booking agents don’t need a copy of anything. They work on the live system. Branches are for changing the software.

Say the travel team asks for roommate preferences before the kickoff. A coding agent adds the feature, including a new column in the bookings table. It shouldn’t try that on the live bookings. So it makes a branch, the practice kitchen: a copy of the database with real-shaped data, where it can run the change, run the tests and break things. If it goes wrong, you throw the branch away, and the live bookings are untouched.

But sooner or later, food goes out to the dining room. Real bookings land in the shared database, where people and other agents are working too. That’s where a separate copy stops helping.

Here’s a simple case. At 10:00, one agent puts the wrong home airport in your traveller profile. At 10:05, another agent correctly books a colleague’s flight. At 10:10, you spot the bad profile. If you rewind the whole database to 9:59, you lose your colleague’s booking too. Rewinding can’t pick out the bad change and leave the good one.

So the shared record needs a different kind of protection. I start with three everyday rules:

• Don’t sell the last room twice. The kickoff has a block of 40 rooms at the hotel. If two agents check that one room is left and then both book it, two colleagues are sharing a room they didn’t agree to. Checking and changing have to happen as one step. In database terms: a conditional update, or a transaction with the right locking or isolation.
• Give every request a number. If an agent retries a booking after a timeout, it should reuse the same request number. The system then returns the recorded outcome instead of booking again. If the outcome is still unknown, the agent checks with the booking service or pauses. In database terms: a required, unique operation ID, saved in the same transaction as the change. If an outside booking service makes the booking, it has to recognise the number too.
• Some things can’t be rewound. No database rollback cancels an airline charge or unsends a confirmation email. Those steps must be safe to retry, checked afterwards with the source of truth, and paired with an undo where one exists, like a cancellation.

None of these are new. Good systems have followed them for decades. Agents just make them matter more, because no person is watching each change.

That’s why I lean towards a transactional database for the record. It’s my judgement from building, not a measured finding. I want code and the database enforcing these rules, not the prompt.

Open questions

• Which of the DBA’s decisions can safely become policy, and which should always stay with a person?
• When agents create thousands of short-lived databases, where does the view across all of them live?

In the last part I look at where Databricks Lakebase fits, and what it still leaves to you.

Sources

Sources checked on 2026-10-25. Dates are publication dates unless noted.

• AWS, CloudFormation announcement, 2011-02-25.
• AWS, Introducing the Aurora storage engine, 2016-12-12.
• Snowflake, The Snowflake Elastic Data Warehouse, SIGMOD 2016.
• Databricks, Neon acquisition announcement, 2025-05-14. Self-reported figure.
• Supabase, funding and Turso announcement, 2026-10-02. Self-reported figure.
• PostgreSQL, Transaction isolation, current docs, no date shown.