How Natural-Language-to-SQL Actually Works
Typing a question and getting a chart looks like magic. Under the hood it's a pipeline: resolve the entities, generate the SQL, validate it, execute it, explain the result. Here's each stage.
Ask a question in plain English, get an answer from your database. On the surface it feels like one step. It isn't, and understanding why is the difference between a tool that impresses in a demo and one you'd trust in production.
A real natural-language-to-SQL system is a pipeline. Each stage exists to fix a specific way the previous stage can go wrong. Here's the whole path a question travels.
Stage 1: Entity resolution
Before you can write SQL, you have to know what the question is about. "How many enterprise accounts churned in Q2?" contains business entities, like "enterprise accounts," "churned," and "Q2," that have to map onto real things: tables, columns, values, and date ranges in your schema.
This is where fuzzy human language meets exact database vocabulary. "Enterprise" might be a tier value spelled ENT. "Churned" might mean status = 'cancelled', or it might mean no activity in 90 days, which is a business definition rather than a column. A resolution step identifies these entities, matches them against actual values in the data, and produces a structured plan of what to query. When something is genuinely ambiguous, this is the stage that knows to ask a clarifying question rather than guess.
Stage 2: SQL generation
Now the structured plan becomes an actual query. This stage converts intent into dialect-specific SQL, since Postgres, MySQL, and SQL Server don't speak identical dialects, using the target database's stored context: its schema, table and column descriptions, synonyms, and business rules.
That context is what makes the SQL correct rather than merely plausible. Without it, a model guesses table names and join logic. With it, generation is grounded in how your database is actually shaped and how your business actually defines things.
Stage 3: Validation
A generated query is a candidate, not a command. Before anything runs, it's validated: parsed to confirm it's a read-only SELECT, checked against a blocklist that rejects any mutation or schema change, and failed closed if it can't be cleanly verified.
This is the stage that makes pointing an AI at a production database safe. Generation is where the model has freedom. Validation is the gate where it doesn't.
Stage 4: Execution
The validated query runs against your connected database, scoped to your tenant and within bounds. Statement timeouts stop runaway queries, and row caps keep result sets sane. The output is real rows from your real data.
Stage 5: The plain-language answer
Rows in a table answer the literal question but not the human one. The final stage summarizes the results back in natural language, something like "Enterprise churn was up 12% over Q1, driven by three large accounts," and renders a chart when it helps. This closes the loop: a plain-English question in, a plain-English answer out, with the table and the query available underneath for anyone who wants them.
Why the pipeline matters more than the model
It's tempting to think the whole thing is "a good LLM." But the model is one component. The pipeline is what makes it reliable. Entity resolution stops it from querying the wrong thing, context stops it from hallucinating schema, validation stops it from doing damage, execution bounds stop it from taking down your database, and the summary makes the result usable.
A single prompt can produce SQL. A pipeline produces SQL you can put in front of your business. That's the architecture Cazper is built on, with each stage earning its place by catching a failure the others can't.