Natural language SQL needs guardrails, not just better prompts

Natural language SQL demos are easy.

Ask a question. Get an answer.

Production is different.

The real workflow should look more like this:

1. Map the question to curated schema context
2. Check tenant and role scope
3. Prefer approved views for known metrics
4. Estimate query cost before execution
5. Enforce row limits, timeouts, and query budgets
6. Return answer provenance with the result

The dangerous version is letting the model discover raw tables and generate whatever SQL seems plausible.

A read-only role helps, but it is not enough by itself. A read-only query can still expose sensitive columns, scan too much data, cross tenant boundaries, or produce a confident answer from stale schema context.

The right question is not “can the model write SQL?”

It is: can the system keep the model on an approved path when the question is vague, expensive, or risky?

Longer version: Natural language SQL guardrails

Better prompts are useful. Guardrails are what make the workflow operable.