Detailed definition
Text to SQL is the technique of having a large language model take a user's natural-language question and emit a SQL query directly, which is then executed against a data warehouse. The model is typically given the question plus some serialized schema context (table names, column names, sometimes sample rows) and is expected to produce SQL that answers the question. NL2SQL and text2sql refer to the same approach.
Text to SQL has useful niches. It works reasonably well for prototypes, developer tools, and ad hoc data exploration by users who can read SQL and catch obvious mistakes. The disagreement is about whether it should be the foundation of a governed BI system used by non-technical business users, which is what most generic "AI for your data warehouse" demos imply.
A text-to-SQL system is not the same thing as natural-language analytics done over a semantic layer. The user-facing experience can look identical (a chat box, an answer, a chart), but the engineering underneath is fundamentally different.
Why it matters
Most of the AI BI demos a buyer encounters in 2026 are text to SQL under the hood. The category is crowded with tools that wrap a frontier model around a schema and call the result "AI analytics." That distinction is invisible in a polished demo on a clean dataset, but it determines whether the same product holds up against a real warehouse with overlapping table names, multiple revenue definitions, time-zone-sensitive metrics, and row-level security.
Naming text to SQL clearly is what lets a reader judge whether an AI BI tool's promise is structurally trustworthy or only convincing on the vendor's curated sample data.
How it works
A text-to-SQL pipeline typically runs four steps:
- The system serializes some portion of the warehouse schema (table names, column names, sometimes column descriptions, sometimes RAG-retrieved query examples) and packs it into the model's prompt.
- The model generates a SQL query.
- The query runs against the warehouse.
- An optional second LLM call narrates the result back to the user.
The structural property that drives most of the downsides is what is not in this pipeline. The model has no persistent business vocabulary, no reusable metric definitions, no enforced permission model, and no way to ensure that two questions about the same business concept produce consistent SQL. Every query starts from scratch.
Practical examples
- "Revenue by region" returns different numbers from one week to the next because the model picks different revenue and region columns on different runs.
- A join across two transaction tables uses the wrong key and silently drops a meaningful share of rows, with nothing in the answer surfacing that something is missing.
- A "customers" table has more than one business meaning in the warehouse (billing customer vs. usage customer); the model picks whichever resembles the wording of the question.
- "Active users last month" is answered with last calendar month on one run and trailing thirty days on the next, because nothing in the schema tells the model which definition the business uses.
- A schema rename in the warehouse quietly breaks dozens of saved questions, because there is no semantic abstraction between the question and the columns.
Common pitfalls
- Benchmark wins do not generalize. Public text-to-SQL benchmarks use clean schemas with clear naming and well-formed questions. Real warehouses are messy.
- More prompt context (longer system prompts, RAG over schema, retrieved example queries) reduces the most obvious errors but does not change the structural issue. The model is still guessing business semantics per query.
- Fine-tuning on a customer's schema tends to make wrong answers more confident, not more correct, because the model gets fluent in the warehouse without gaining a governed definition of what anything means.
- Text to SQL is not the same as natural-language analytics. The user-facing experience can look identical. The architecture underneath decides whether the answers are reproducible, governable, and safe to act on.