Ask a data analyst how many customers placed a repeat order last quarter, and they will open a SQL editor. Ask most other people in the company, and they will open a ticket.

Text-to-SQL is the idea of closing that gap: a person types a question in plain language, and software turns it into a query the database can run. It is one of the most useful things large language models have made practical, and one of the easiest to get subtly wrong.

What text-to-SQL does

A data warehouse such as Google BigQuery stores business data in tables: orders, customers, products, invoices. To get an answer out, someone writes SQL, a precise language that says which tables to read, how to join them, which rows to keep and how to summarize them.

Text-to-SQL takes a question like "which products sold more this quarter than last?" and produces that SQL. A simplified result might be a query that sums order value by product for two date ranges and compares them.

The person asking never sees the query unless they want to. They see the answer.

Why it is harder than it looks

Generating syntactically valid SQL is the easy part. Modern models do it well. Generating the right SQL for a specific business is where the work is.

  • Ambiguous words. "Recently", "active customer", "significant drop" and "top accounts" all need concrete definitions. Two analysts in the same company can define them differently.
  • Business meaning lives outside the schema. A column called status with values 1 to 7 tells a model nothing. Which value means "cancelled" is knowledge, not structure.
  • Many plausible tables. Large warehouses often hold several versions of the same thing: raw orders, cleaned orders, orders by day. Picking the wrong one returns a confident, wrong number.
  • Joins multiply mistakes. Joining orders to customers to regions is routine for an analyst and a common place for double counting when done carelessly.
  • Time is tricky. Fiscal years, time zones and "last quarter" relative to today all change the answer.

The failure mode that matters is not an error message. It is a plausible number that is quietly wrong.

What good text-to-SQL systems add

Useful systems treat query generation as one step in a longer process:

  1. Understand the question. Work out what is being measured, over what period, compared with what, and for whom.
  2. Find the right data. Identify which tables and fields hold the answer, using knowledge of how this organization's data is actually used.
  3. Generate and run the query.
  4. Check the result. Empty results, implausible totals and mismatches with the question should be caught before anyone sees them.
  5. Explain the answer. Turn the numbers into a short summary, key figures and a chart where it helps.
  6. Keep the context. "Which of those were top-20 accounts last year?" should work as a follow-up without starting over.

Steps 2 and 4 are where most of the engineering goes, and where products differ most.

Trust: seeing how the answer was produced

For business use, an answer you can't check is an answer you can't act on. Three properties matter:

  • Traceability. The answer should show which data it came from and, for anyone who wants it, the query behind it. An analyst should be able to verify a surprising figure in minutes.
  • Permissions. Plain language doesn't change who is allowed to see what. A text-to-SQL layer must respect the same access rules as the rest of your data stack.
  • Read-only by default. Answering a question should never change data. Actions belong in a separate, controlled workflow.

When text-to-SQL works well

It earns its keep where questions are frequent, specific and time-sensitive, and the data already sits in a governed warehouse:

  • Sales heads asking which accounts are buying less.
  • Procurement teams asking which products depend on one supplier.
  • Operations teams asking what changed this week.
  • Finance and banking teams watching early signs of risk by product or region.

It works less well on messy, undocumented data, or when the question needs information that isn't in the database at all.

How to evaluate a text-to-SQL tool

Bring your hardest real questions, not a prepared script, and check:

  • Does it connect to where your data already lives?
  • Does it get your business definitions right, or can you teach it?
  • Can you see the sources and the query behind each answer?
  • Does it respect existing access controls?
  • What does it do with a question it can't answer? Saying so is the right behaviour.

Where QuerySafe fits

QuerySafe Intelligence uses text-to-SQL as one step of a larger process. It connects to your Google BigQuery data, lets people ask questions in plain language, and returns answers designed to show the data they draw on. You can read more on how it works, or bring us your hardest data question.