Every text-to-SQL tool treats SQL as the thing being generated.
That's the mistake. SQL isn't the answer — it's the assembly language underneath one.
Nobody asks a compiler to try
A C compiler doesn't produce probably-correct assembly. It either compiles or it fails with an actionable error. That guarantee is the entire value proposition, and every compiler engineer takes it for granted.
Treat SQL the same way and the architecture reorganises itself.
The pipeline that follows
| Stage | Compiler analogue | What it prevents |
|---|---|---|
| Intent parsing | Lexing / parsing | Ambiguous natural language reaching the planner |
| Concept resolution | Symbol table lookup | Guessed column semantics |
| Type checking | Type system | A metric requested at an invalid grain |
| Join proof | Linking | Invented relationships |
| Policy injection | Static analysis pass | Unauthorised rows being read |
| Emission | Code generation | Dialect drift across engines |
The LLM's job shrinks to the first stage — turning language into structured intent. It stops being the component that decides what your business means, which is the only role it was never suited for.
Why "dialect-perfect" is the right bar
Generic SQL is a lowest common denominator. Snowflake, BigQuery, Databricks and Postgres differ in date handling, window semantics, quoting and type coercion — and those differences are exactly where silently wrong results come from.
A compiler targets a specific backend, the way a real compiler targets an ISA. Anything less pushes the incompatibility onto the user, who discovers it as a number that's slightly off.
The line that matters
The difference between generating SQL and compiling to SQL is the difference between a plausible answer and a provable one.
The full breakdown — the compilation pipeline in detail, the type system, and dialect targeting — is here:
👉 SQL as a Compiler Target: The Future of Governed Enterprise AI
Originally published at colrows.com/blogs/sql-as-compiler-target
Top comments (0)