Read-only by default: safe AI for SQL databases

An AI assistant that writes SQL for you is useful. An AI assistant that runs that SQL against your database without asking is a liability waiting to happen. The difference between the two is a design decision, and it is worth being deliberate about it.

This article is about that decision: why an AI SQL assistant should be read-only by default, why writes should require an explicit, human confirmation, and what information should — and should not — ever leave your database and reach a language model.

Disclosure: I work on SQL Sage, which I’ll use later as a concrete example. The principles below hold regardless of which tool you use.

Why should an AI SQL assistant be read-only by default?

Because the cost of a mistake is asymmetric. A SELECT that the model gets wrong returns the wrong rows — annoying, but harmless and reversible: you read the result, see it’s off, and ask again. An UPDATE or DELETE that the model gets wrong changes or destroys data. On a production system, that can be unrecoverable without a restore.

Language models are probabilistic. They are very good at producing plausible SQL, and plausible is not the same as correct. A query can be syntactically valid, run without error, and still mean something different from what you asked — a join that fans out rows, a WHERE clause that omits a predicate, an UPDATE without the filter you assumed was there. When the only thing standing between a generated statement and your data is “the model was confident,” you have no safety margin at all.

Read-only by default flips the default from act to propose. The assistant can read freely — schema, query results, explain plans — and generate any statement you ask for. But a statement that changes data or structure doesn’t execute on generation. It waits.

What’s the difference between reading and writing, and why draw the line there?

The line is between statements that observe and statements that mutate.

SELECT observes. It can be slow or expensive, but it doesn’t change the state of your database. (Edge cases exist — a SELECT that calls a function with side effects — but as a category, reads are safe to run.)

INSERT, UPDATE, DELETE, MERGE (DML) change data. CREATE, ALTER, DROP, TRUNCATE (DDL) change structure, and some of those are catastrophic and fast: DROP TABLE and TRUNCATE don’t ask twice and don’t fill a transaction log you can roll back from casually.

Drawing the safety boundary exactly at read-vs-write is clean because it maps onto something the database itself already understands. You are not asking the AI to judge whether a statement is dangerous — you are classifying by statement type, which is deterministic. SELECT runs. Everything else stops and asks.

What does “explicit confirmation” actually mean in practice?

It means a human sees the exact statement, in full, before it runs — and performs a deliberate action to approve it. Not a checkbox buried in settings that you ticked once and forgot. A per-statement gate.

Good confirmation has a few properties:

The statement is shown verbatim. You approve what will run, not a summary of it.
The default answer is “no.” Closing the dialog or hitting escape must not execute anything.
Reads don’t trigger it. If every SELECT nags you, you’ll learn to click through everything, including the DELETE. Confirmation fatigue is a real failure mode; the gate has to be rare enough to stay meaningful.

A stronger version of this exists at the connection level. Some database engines let you open a session that is physically read-only — the server itself rejects writes. When that’s available, it’s better than an application-level check, because it holds even if the application has a bug. In SQL Sage for DBeaver, for example, read-only is engine-enforced on PostgreSQL, MySQL, and MariaDB: the write is refused by the database, not just by the UI. On the other engines and in the SSMS add-in, the model stays read-only by default and DML/DDL requires your confirmation before it runs.

Is it safe to use an AI assistant on a production database?

It can be, if two things are true: writes can’t happen without you, and the data itself isn’t being shipped off to the model.

The first we’ve covered. The second is where a lot of “AI for your database” tools are vague, and it’s the question you should ask hardest.

To write correct SQL, a model needs to know the shape of your database: table names, column names, types, relationships, perhaps a few constraints. That’s the schema — and reading it from the live database instead of guessing is a separate, equally important condition for correctness. The schema plus the text of the SQL you’re working on is enough for the model to be genuinely useful — to autocomplete, to explain a query, to suggest a join, to find the bug in a GROUP BY.

The model does not need the contents of your rows to do any of that. Your customers’ email addresses, your transaction amounts, your users’ personal data — none of it is required to generate a query. So by default, none of it should leave the database. Schema and SQL text: yes. Row data: no.

If you ever do want the model to see sample rows — say, to reason about messy data — that should be an explicit, per-session opt-in, with a clear understanding that those rows are now going to an external model. It should never be the silent default.

What should and shouldn’t reach the model?

A short, checkable list:

Reaches the model (needed to help):

Schema: table and column names, data types, keys and relationships
The SQL text you are writing or asking about
Query structure and error messages you choose to share

Does not reach the model (not needed, and sensitive):

The actual rows returned by your queries
Any personal, financial, or regulated data stored in those rows
Credentials and connection secrets

There’s also the question of whose model it is. An AI SQL tool that routes your schema through its own backend is one more party in the chain. A keyless design — where the tool talks to your own AI account (your Claude or ChatGPT) directly, rather than proxying through the vendor — keeps the vendor out of the data path entirely. SQL Sage works this way: it uses your own account, so there’s no middleman holding your schema.

The takeaway

The safety model for AI at the database isn’t complicated, and it isn’t about trusting the model more. It’s about defaults:

Read-only by default. Reads run; writes wait.
Explicit, per-statement confirmation for anything that mutates — ideally engine-enforced where the database supports it.
Schema and SQL go to the model; rows don’t — and sending rows is a deliberate opt-in, not a default.

An AI assistant that follows these three rules can sit against a production database and be genuinely helpful without ever being able to quietly damage it or leak it. One that doesn’t follow them is asking you to trust a probabilistic system with irreversible actions — and that’s a trust you shouldn’t have to extend.