How Deltabase lets agents change database schemas without letting them delete everything.

Here is a conversation an AI agent can have with itself:

Agent: I'm going to drop the legacy_orders table. Continue?
Agent: Yes.

That’s the whole conversation. Nobody else was in the room. The agent asked a question, gave it deliberate, careful consideration for roughly zero milliseconds, and confidently approved its own plan. It’s like a toddler asking itself whether it may have a cookie. It doesn’t know any better.

attachment image

A lot of “human in the loop” safety looks like this right now: a loop where agents do everything. And the human checks when they’re bored of scrolling social media.

I know because I’ve spent a long time building a database platform where AI agents change schemas all day, and much of that time has gone into stopping exactly this.

How I got here

Deltabase started as a dashboard I used alongside Supabase. Then Supabase became temporarily inaccessible in India, which took my app Slate down with it. And I had to explain to my users why I couldn’t do anything about them not being able to access their data in Slate.

A reasonable person would have waited it out. I built my own database platform.

attachment image Supabase is down. Me: I'll just build my own platform

Deltabase now runs Slate and around 30 other apps, most of which I also built. That makes me its biggest customer, its only on-call engineer, and the person filing the angry tickets.

I build nearly everything with AI agents now. That’s how I ship fast. It’s also how I got to know my agent’s personality: tireless, extremely confident, and wrong in new and creative ways.

That’s fine for code. If the agent breaks a source file, I revert the commit and we never speak of it again. A database is different. If the agent drops a table full of data, reverting the schema brings back the table. It does not bring back the data. You get a beautiful empty table, like a museum display case after the heist.

So the question became: how do you let an agent move fast without trusting it to judge every database operation correctly?

My first answer was wrong. So was my second. But eventually, I somehow figured it out.

Attempt 1: Ask nicely

The obvious safeguard is a confirmation prompt, and you’ve already seen how that goes. The agent proposing the change and the agent approving it are the same agent. A confirm: true flag doesn’t prove anyone reviewed anything. It proves someone typed true, and agents are extremely good at typing true. One can get a secondary agent to approve it but it unfortunately has the same training as the first so there’s not much benefit.

Attempt 2: Get a receipt

So Deltabase separates planning from doing. Before an agent changes anything, it asks for a preview: the exact operations, their order, the SQL that would run, a risk class for each step, and a planHash that fingerprints that specific plan.

The hash is a receipt. When the agent comes back to apply the change, it hands over the receipt. Deltabase rebuilds the plan from scratch against the live database, and if the new plan doesn’t match, the apply is refused with PLAN_DRIFT. Back to preview.

This matters because databases don’t hold still while you review them. Another agent can change the schema in between. (Ask me how I know.) An approval for the plan you saw at 2:00 is not an approval for the plan that exists at 2:04.

That was the most useful lesson of the whole project, so here it is with no jokes: a check at the start of a workflow doesn’t protect the moment of the action. Either you check again right before acting, or you assume things changed.

Attempt 3: Get an actual human

A receipt proves the plan didn’t change. It doesn’t prove anyone looked at it. The agent can preview, pocket the hash, and apply, all in one breath. Approval was still just part of the conversation.

So when an agent makes a destructive change through Deltabase’s MCP server, it needs an approval it can’t produce itself. A human runs a second preview with their own login, not an API key, and Deltabase issues a consent token. The token is bound to that exact plan, that person, that database, and those specific destructive operations. It expires in five minutes and works once. If the backend restarts, every outstanding token dies, which errs firmly on the side of making me do things twice.

Without a token, the agent gets DESTRUCTIVE_CONSENT_REQUIRED, the most Victorian error message I have ever written.

In the interest of honesty: the “human review screen” is currently me making an API call by hand and pasting the token into the chat, like a nightclub bouncer handing out wristbands. The boundary is real. The décor is not.

One catch, stated plainly: this works only because the agent never holds my login session. The agent has an API key; I have my session. If an agent ever got my session, it would be me, and no token design survives that.

Attempt 4: Check the table again, with the door locked

Then came the next problem: tables are not furniture. They change.

Say the agent proposes dropping legacy_orders, and the preview shows it’s empty. I approve. In the minute between my approval and the DROP, a forgotten cron job writes six rows to it. “Delete an empty table” has quietly become “delete six orders,” and nobody approved that.

So Deltabase checks DROP targets twice: once at preview, and again at apply, after locking the tables inside the same transaction that runs the DROP. If a table I reviewed as empty now has rows, my token no longer covers it, and I have to review again.

If a table already has data when I review it, approval alone isn’t enough. I also have to separately acknowledge that the data is gone for good. Which brings me to the uncomfortable part.

“Reversible” is doing a lot of work

“Reversible” is a word that makes everyone feel better and promises nothing.

Deltabase takes backup tables before it updates rows or truncates a table. It does not back up a table before dropping it. So the operation you’d most like to undo is the one with no backup. I know. I’ve made peace with this by refusing to hide it: every screen that asks for that acknowledgement says plainly that the data isn’t coming back.

The goal isn’t to promise nothing will go wrong. It’s to show the consequences before the action and keep a way back wherever one actually exists.

Not everything needs a notary

All of this could easily turn into a system where adding a column takes three signatures and a blood sample. Developers would route around it within a week, and I’d be the first one to do so.

So the friction scales with how much it can hurt:

  • Additive changes on dev just go.
  • Dropping constraints and indexes on verified dev databases needs no consent, because those drops remove a rule, not a row. This has run for real against Slate’s dev database, uneventfully, which is the highest compliment a database change can receive.
  • On staging, agents can make additive changes at most, and only where the app allows it.
  • Prod is humans only. Agents can preview prod all they like. They cannot touch it.

Deciding where those lines go was the hardest part, and I’m sure some of them are still in the wrong place. But they won’t hurt where it really matters.

What I actually learned

I started out thinking agent safety was mostly about getting the model to decide better: better prompts, better tool descriptions, more context. And with coding agents, better hooks. Those help.

But the database taught me to stop expecting the agent to be careful and start building a system that assumes it won’t be. Agents misunderstand. I approve things without reading closely. Tables fill up between two steps. Backups don’t exist for the one thing you most want back. The useful question isn’t how smart the agent is. It’s how much good work it can do inside a system that catches mistakes before they get expensive.

As for legacy_orders: it’s still there. It has six rows. Nobody knows what they’re for. But I’m not dropping it.

Deltabase is in open beta at deltabase.live. Sign in with Google. Your tables will thank you.