Skip to content
Ultra BI
Guides

NL-to-SQL, Explained: Plain English to a Query

·Ultra BI Team ·7 min read

TL;DR

NL-to-SQL is the technique that turns a plain-English question into a database query an engine can run. A model reads your question and your schema, then writes SQL that returns the answer. It's the engine room of natural-language analytics — and generative BI builds on it by running the query and explaining the result.

Ask a question, get a query. That’s the promise of NL-to-SQL — and it’s the foundation under every “ask your data in plain English” product. But the technique has real strengths and real limits, and understanding both tells you what to look for in a tool built on it.

How NL-to-SQL actually works

An NL-to-SQL system needs two things: your question and your schema — the tables, columns, and relationships in your database. A language model reads both, infers which tables answer the question and how they join, and writes SQL. The query runs against your data, and the rows come back.

The schema is the key ingredient. Without it, a model is guessing at table and column names. With a good description of your data, it can resolve “active customers last month” into the right joins, filters, and date logic.

Where it breaks down

NL-to-SQL is powerful but not magic. It struggles when:

  • The question is ambiguous. “Best customers” — by revenue, recency, or lifetime value? A good system asks or states its assumption.
  • The schema is messy. Cryptic column names and undocumented tables make the model guess.
  • The metric is non-obvious. “Net revenue retention” has a specific definition; the model has to encode it correctly.

The failure mode that matters most is a query that looks plausible but is subtly wrong. A number with no visible logic behind it is impossible to trust.

Why the visible query matters

The single most important feature of any NL-to-SQL tool is that it shows the query it ran. When the SQL is visible, a technical user can confirm the joins and filters are right — and an incorrect query becomes a quick fix instead of a silent error in a board deck.

From query to answer: generative BI

NL-to-SQL returns rows. A real business question needs more than rows — it needs the chart, the context, and the “what changed and why.” Generative BI wraps NL-to-SQL in that full report: it runs the query, visualizes the result, writes a narrative, and keeps the SQL one click away. The technique is the engine; the report is the product.

If you’re evaluating tools, don’t just ask whether they do NL-to-SQL — almost all of them do now. Ask whether they show the query, whether they explain the result, and whether they run on a copy of your data so analysis never slows production.

FAQ

Is NL-to-SQL accurate enough to trust?

It's good and improving, but it isn't infallible — ambiguous questions or messy schemas can produce wrong queries. That's why the query should always be visible, so a person can verify the logic before trusting the number.

What's the difference between NL-to-SQL and generative BI?

NL-to-SQL produces the query. Generative BI runs it and assembles a full report — charts, a written narrative, and the query itself. See what generative BI is for the full picture.

Does NL-to-SQL work on any database?

In principle, yes — any source it can read the schema of. Ultra BI applies it across PostgreSQL, Snowflake, and more.

Ask your first question in 60 seconds

Connect a source and get a full, inspectable report back — no analyst, no setup.