Text-to-SQL

Text-to-SQL takes a question such as "which regions missed their collections target last quarter?" and produces a SQL statement that a database can execute. The model is given the schema, sample values, business definitions and often a few worked examples, then asked to write the query. A production system wraps this with validation: the query is parsed, checked against an allow-list of tables, limited to read-only statements, executed with a row and time cap, and the result is returned with the SQL visible so a human can inspect it.

It is not a chatbot that "knows your numbers". The model never sees the whole database; it sees the schema and whatever context you give it. Accuracy therefore depends far more on a clean semantic layer and a good golden question set than on the model choice. It is also distinct from a BI tool's search box, which matches saved reports rather than composing new queries.

The common confusion is treating a demo that answers ten hand-picked questions as a finished product. Real usage is messier: ambiguous column names, fiscal-year quirks, joins that silently double-count. Those are the problems a Text-to-SQL build actually spends its time on.

• CTO / Head of Engineering: this is a data-modelling problem wearing an AI costume; the schema and definitions you expose decide accuracy, and the guardrails around execution decide whether it is safe to ship.
• Data lead: every ad-hoc request that currently lands in your queue is a candidate; the trade-off is that you now own the definitions the model relies on.
• CFO: a wrong number in a board pack is worse than no number, so insist on visible SQL, a tested question set and a stated accuracy figure before trusting it.
• Product manager: for a SaaS product, an "ask your data" feature is a credible premium-tier capability if it is grounded in your own tenant's data and permissions.

Text-to-SQL exists because most of the people who need answers from a database cannot write queries, and the analysts who can are a bottleneck. Every hour spent on "can you pull me the numbers for..." is an hour not spent on analysis. The trade-off is trust: a model can write syntactically perfect SQL that answers a subtly different question. That is why the practice pairs the model with a semantic layer, an evaluated question set and read-only execution, rather than pointing it at production and hoping.

• A SaaS admin console where customers ask "which accounts dropped usage this month?" and get a table drawn only from their own tenant.
• An NBFC operations team querying loan-book performance by branch and product without waiting for the MIS team.
• A retail chain asking for sell-through by SKU and store during a sale, with the query visible for the category manager to check.
• A hospital network reporting bed occupancy and average length of stay per department from its HIS database.
• A logistics operator checking on-time delivery by hub and carrier, filtered to the hubs the user is allowed to see.

Technique / practiceA technique that combines prompt design, schema modelling and query validation. It is the core of Eazyware's natural language data querying service, and is evaluated against a golden question set before any user touches it.

Eazyware service that covers it: Natural Language Data Querying. Starting prices are on the pricing page.