NL2SQL — natural language to SQL — converts a plain-English question into a database query. Type "what was revenue by region last quarter?" and get back a chart, not a JOIN you have to write yourself. In 2026, the best implementations hit 85-90% accuracy on well-modeled schemas. That's good enough for a business user to self-serve. It is not good enough to run unsupervised against production without a human glancing at the SQL first.
This post is about the gap between those two sentences.
How NL2SQL actually works
Under the hood, every serious NL2SQL system runs a pipeline, not a single LLM call. Skip a stage and accuracy falls off fast.
1. Schema context injection. The model needs to know your tables, columns, types, and relationships exist before it can reference them. This is usually a prompt-time step: pull table/column names (and ideally descriptions) from information_schema or a catalog, and inject the relevant subset into context. "Relevant subset" matters — dumping all 400 tables into every prompt burns tokens and buries the ones that matter.
2. Ambiguity detection. "Revenue" is not one number. It could mean MRR, ARR, total invoiced, recognized revenue, or gross bookings. A naive system picks one and moves on. A better one recognizes the term is overloaded and either asks a clarifying question or defaults to a documented definition (see the glossary section below).
3. SQL generation. The LLM produces a query given the question, the schema context, and (if it exists) the glossary. This is the part every vendor demos and the part that's genuinely commoditized now — GPT-4-class models write syntactically correct SQL reliably. Syntactically correct is not the same as semantically correct.
4. Validation loop. Before anything reaches the user, the system should run an EXPLAIN, catch syntax errors, and — ideally — self-correct on failure by feeding the error back to the model. Without this step you're shipping raw LLM output straight to a warehouse, which is how you get a Friday-afternoon Slack message asking why a dashboard is broken.
5. Result formatting. A single aggregate becomes a number. A time series becomes a line chart. A grouped breakdown becomes a table or bar chart. This sounds like a nice-to-have but it's actually part of correctness — a user who gets a 50-row table for "what's our churn rate?" has been technically answered and practically failed.
Most of the AI hype focuses on step 3. Most of the actual failures happen in steps 1, 2, and 4.
What determines accuracy (it's not the model)
If you've evaluated more than one NL2SQL tool, you've probably noticed the same model (often the same underlying LLM) performs wildly differently across products. That's because accuracy is dominated by inputs the model doesn't control.
Schema quality matters more than model quality. A column named revenue_monthly gets interpreted correctly almost every time. A column named col_47 or amt_m doesn't, no matter how good the model is. We've watched the same query go from ~90% to ~60% accuracy purely by swapping a demo schema (clean, documented) for a real production one (legacy names, no descriptions, ambiguous abbreviations). If you want a bigger single lever than switching models, it's cleaning up your schema metadata.
Glossary and synonym mapping close the gap models can't close on their own. "Churn" isn't in your schema — it's a business concept computed from customers_cancelled / customers_start, and different teams sometimes compute even that differently (logo churn vs. revenue churn). Without an explicit mapping, the LLM guesses at a formula that looks plausible and is often wrong. With one, the same question resolves the same way every time. This is the same problem — and the same fix — described in how to define your metrics once: NL2SQL accuracy and metric-definition discipline are the same project wearing different clothes.
Table count changes the search space. With 5-20 well-organized tables, schema-context injection works cleanly — the model can reasonably "see" the whole schema. Past a couple hundred tables, you need retrieval (pull only the relevant tables per question) or accuracy degrades, because either you truncate context and miss the right table, or you include everything and the model gets distracted by irrelevant columns with similar names.
Join complexity is the most underrated variable. Single-table queries — filter, aggregate, group — sit around 95% accuracy on a decent schema. Add a 3+ table join and accuracy drops toward 70% unless the system has explicit relationship hints (foreign keys, or a documented join path). The model can usually guess a join. Whether it guesses the right join — the one that doesn't fan out rows or silently drop a filter — is a coin flip without help.
Tools that offer NL2SQL in 2026
| Tool | Approach | Accuracy (reported) | Pricing | Best for |
|---|---|---|---|---|
| ThoughtSpot Sage | Proprietary search + LLM | High, on curated ThoughtSpot data models | Enterprise, $50k+/yr | Large orgs already on ThoughtSpot |
| Databricks AI/BI | Unity Catalog metadata + LLM | High, on well-modeled Databricks tables | Included in Databricks | Teams already living in Databricks |
| ChatGPT + plugin/connector | Generic GPT-4-class model | Medium — no persistent schema context by default | ~$20/mo | Ad-hoc, one-off questions, not production |
| Mode AI | SQL assistant inside Mode | Medium | Included in Mode ($35/user/mo) | Existing Mode users |
| Fastero | Schema-aware + glossary + validation loop | High, on connected sources | Free tier / $49/mo | Small teams, multiple connected sources |
A caveat that applies to every row in this table: "accuracy" numbers are rarely apples-to-apples. Vendors measure on their own benchmark, their own schema, their own definition of "correct." Which brings us to the part nobody puts in the marketing deck.
The accuracy problem nobody talks about
"90% accuracy" is a real number on a curated demo schema — clean names, documented columns, no legacy cruft, five tables, one obvious join path. It is not the number you should expect on your actual warehouse.
Real-world schemas have ambiguous column names (status meaning five different things across five tables), denormalized tables that duplicate the same fact under different names, legacy naming from a system that was migrated twice, and missing foreign keys that force the model to infer a join instead of following one. None of that shows up in a benchmark built to make a demo look good.
The 10% that fails is rarely a random 10%. It clusters around exactly the queries that matter most — the multi-condition, multi-table, "why did this number move" question your CEO asks in the exec meeting, not the "top 10 customers by revenue" softball everyone tests with.
There isn't a way to eliminate this failure mode with a smarter model. The mitigations are structural: a glossary that resolves ambiguous terms before the model has to guess, verified metric definitions for the numbers that actually get reported upward, and human-in-the-loop confirmation whenever the system encounters a pattern it hasn't seen validated before. Treat "confidently wrong" as the failure mode to design against, not "obviously broken" — a query that runs and returns a plausible-looking wrong number is far more dangerous than one that errors out.
Practical guide: making NL2SQL work well
If you're rolling this out against a real warehouse, in order:
- Clean your schema metadata first. Add column descriptions and table descriptions before you touch a model or a tool. This is the single highest-leverage thing you can do, and it's the one everyone skips because it's not exciting.
- Define a glossary. Map the 15-25 business terms people actually argue about — revenue, churn, active user, MRR — to exact SQL expressions. Reuse the format from defining metrics once if you haven't already built one.
- Start with 5-10 common questions and check the SQL by hand. Don't trust the answer — read the generated query. This is how you find out your "revenue" glossary entry excludes refunds when it shouldn't, before it ships to the whole company.
- Set guardrails. SELECT-only (no writes, ever, from a natural-language interface), automatic
LIMITinjection so a vague question can't return 40 million rows, and cost estimation before execution if you're on BigQuery or Snowflake where a bad query has a dollar cost, not just a latency cost. - Build a feedback loop. When generated SQL is wrong, correct it, and feed that correction back into the glossary or the schema context. Accuracy on your specific warehouse compounds over weeks of use — this is the difference between a tool that plateaus at 70% and one that climbs toward 90%.
Honest limitations in 2026
Some failure modes aren't close to solved, regardless of vendor:
- Complex aggregations with window functions — running totals, cohort-based retention, rank-within-group — are still unreliable across every tool we've tested, including our own. The model gets the shape right and the boundary conditions wrong.
- Questions requiring business context the schema can't encode. "Is this a good conversion rate?" has no SQL answer — it needs a baseline, and the baseline lives in someone's head, not a table.
- Cross-database queries. No NL2SQL tool in 2026 handles "join this Postgres table to that Snowflake table" well from a single natural-language question. You're still stitching that together manually or through a separate federation layer.
- Custom fiscal calendars. A "last quarter" that isn't calendar-aligned, or a business that closes its fiscal year in a non-standard month, breaks most implementations' assumptions about date logic. This is a narrow edge case, but it's exactly the kind that erodes trust fast when it hits.
Fastero's approach
- Schema context from connected databases — Fastero auto-discovers tables, columns, and types from whatever you connect (Postgres, BigQuery, Snowflake, and others), so context injection doesn't require you to hand-maintain a schema file.
- Glossary mapping — define "revenue" as
SUM(amount) FROM subscriptions WHERE status = 'active'once, and every question that touches revenue resolves to that definition instead of an improvised guess. - Ambiguity detection — when a question is genuinely underspecified, Fastero asks a clarifying question rather than silently picking an interpretation.
- Guardrails — SELECT-only enforcement, automatic
LIMITinjection, and cost estimation on BigQuery before a query runs.
If you want the fuller picture of where NL2SQL sits inside AI-powered analytics generally, see AI business intelligence: what it actually means in 2026, and for a broader tool comparison, the best AI data analysis tools or, for enterprise search-driven analytics specifically, how Fastero compares to ThoughtSpot.
Want to see NL2SQL running against your own schema, glossary included?
👉 Start your free 30-day trial (no credit card required)
Last updated: July 2026.