Writing ·
Text-to-SQL is the wrong interface for a production database
Draft — replace this with your own argument. It exists so the section has something in it and so you can see the layout render.
The standard way to connect a language model to a relational database is to give it the schema and let it write SQL. It demos well. The model reads twenty table definitions, produces a join, and returns a plausible number.
The trouble starts at the second word of “production database”.
The failure modes are not the ones you rehearse
Everyone worries about DROP TABLE. That one is easy — revoke the grant and it
cannot happen. The failures that actually cost you are quieter:
- A query that is correct but unbounded, and returns four million rows into a context window.
- A join that is syntactically fine and semantically wrong, because the schema encodes a business rule the model never saw.
- A statement that runs without an index and sits on the database for nine minutes at month end.
None of these are security failures. All of them are availability failures, and none of them are caught by “the user is read-only”.
Schemas are not self-documenting
A column called STATUS with values 1 through 7 means something to the team
that built it. The meaning lives in a package, a wiki page, or a person. A model
reading the DDL gets the type and nothing else, and it will guess. It will guess
confidently.
What a curated tool list changes
Replace the schema dump with a list of named operations, each with typed parameters and a description written by someone who knows the domain, and the problem changes shape. The model is no longer authoring database access. It is choosing between things you already decided were safe.
That is a much smaller decision, and a much smaller thing to get wrong.