DBA can run confirmed DDL/DML now — DROP and TRUNCATE still hard-blocked

For a long time we treated write access like a binary: either you were Admin, or you weren’t touching the database through DeepSQL.

That was safer than letting an agent freestyle mutations. It was also wrong for how real teams work.

The pain I kept hitting

In every shop I’ve been in — Oracle days, startups, production Postgres and MySQL — the person who should apply a careful ALTER or a bounded UPDATE is usually a DBA or a senior eng with DBA muscle. Not the person who also manages users, SSO, and who gets Admin.

Those are different jobs. Bundling them into one role means either:

• you hand out Admin so someone can run a confirmed migration, or
• you force every write through the one Admin who already has too many Slack pings.

Both are bad. The first expands blast radius. The second creates a bottleneck and a temptation to bypass the tool.

We built DeepSQL to be the self-hosted AI DBA for Postgres and MySQL — Agent, Brain, Editor, MCP. Read paths were solid. Writes were gated hard. Too hard for the DBA role we already had in the product.

What we shipped

DBA can now run confirmed DDL and DML on the Editor and over MCP, with the same safety gates as Admin.

Same confirmation flow. Same risk classification. Same audit trail. You do not need MANAGE_USERS to do your job as a DBA inside DeepSQL.

That last part matters more than it sounds. User administration and schema/data change authority should not be the same permission. We unbundled them.

So a DBA can:

• review a proposed change,
• confirm it through the gate,
• apply it from the Editor or from an MCP-connected workflow,

…without also being able to create accounts, reset passwords, or reshuffle roles.

Admin stays Admin. DBA stays DBA — with write power that still requires a human yes.

Confirmation is not decoration

If you’ve ever fat-fingered a production statement, you already know why we don’t auto-apply writes from the model.

The agent can draft. The agent can explain. The agent can argue for an index. It does not get to mutate on its own.

Confirmed means a person looked at the statement, saw the risk class, and clicked through. Editor and MCP share that rule. Coding agents talking to DeepSQL over MCP don’t get a back door. Same product, same gates, different surface.

That’s the whole point of putting MCP in front of the backend instead of handing agents raw DB credentials. Credentials are dumb. Policies and confirmation are not.

What we still block

We still hard-block the ops that end careers and weekends:

• DROP (tables, schemas, databases — the family)
• TRUNCATE
• and similar high-risk “make it gone” statements

Not because DBAs never need them. Because when you need them, you need a change window, a backup story, and usually a second pair of eyes — not a convenient button next to “apply index.”

There’s a difference between “apply a confirmed CREATE INDEX CONCURRENTLY” and “empty this table.” One is routine DBA work with recoverable failure modes. The other is a one-way door.

We’re honest about the gap: DeepSQL is not your HA runbook and not your PITR console. It’s an AI DBA agent with a Schema Guardian and execution gates. Those gates are supposed to refuse some things even when the role is powerful.

If we ever loosen DROP / TRUNCATE, it won’t be by accident in a prompt. It’ll be a deliberate product decision with louder confirmation, stronger scoping, and probably a separate capability flag. Until then: blocked.

Schema Guardian still sits in front

Confirmation answers “did a human say yes?” Schema Guardian answers “is this change dumb against this schema?”

Those are different questions. You want both.

Guardian is the deterministic risk layer — classify the statement, surface what’s dangerous, refuse what’s out of policy — before any LLM narration softens the story. The model is great at explaining. It’s not what I want deciding whether TRUNCATE public.orders is fine because someone typed “clean up staging” in chat.

Lived version of this: most of the scariest production incidents I’ve seen weren’t exotic. They were a statement that looked local, ran global, and had no undo that was faster than restore. Tools that make writes easy without making refusal easy just accelerate that class of mistake.

So yes — DBA can confirm DDL/DML now. Guardian and the blocklist still get a veto.

Why Editor and MCP both

If we only opened confirmed writes in the UI, half the workflow would still live outside DeepSQL. People already ask coding agents to draft migrations. MCP is how those agents talk to our gates instead of talking past them.

Parity matters. “Works in the Editor, fails over MCP” (or the reverse) is how trust dies. Same role. Same confirmation. Same blocks.

Soft line on what this is not

This is not “agents now own your schema.”
This is not “Admin-lite with DROP enabled.”
This is “the DBA role can do DBA work under the same confirmation model Admin already had, without user-admin powers, and without the nuclear options.”

If you wanted a pitch deck, this isn’t it. If you wanted the honest changelog: we moved write authority to the right role, kept the human in the loop, and left DROP / TRUNCATE on the floor where they belong.

Try the OSS build at github.com/DeepSQLAI/deepsql or deepsql.ai if you want to kick the gates yourself.

---

Venkat Sakamuri · Founder, DeepSQL · Peer DBA/eng building a self-hosted AI DBA for Postgres & MySQL · venkat@deepsql.ai