Text to SQL Solution: a practical implementation guide
How do you implement text to SQL solution?
Implement a text to SQL solution in five stages: inventory the questions people actually ask, build a semantic layer that fixes definitions, retrieve the relevant schema instead of prompting the whole warehouse, generate and validate read-only SQL, then gate every release on an eval set of known-correct queries.
Implement a text to SQL solution in five stages: inventory the questions people actually ask, build a semantic layer that fixes what each metric means, retrieve only the relevant part of the schema rather than prompting the whole warehouse, generate and validate read-only SQL before execution, and gate every release on an evaluation set of known-correct queries.
This guide walks each stage in the order we build it, names the decisions that are expensive to reverse, and shows the architecture that separates a system analysts trust from one they check by hand and then stop using.
Stage one: the question inventory
Do not start with the schema. Start with two weeks of the questions your analysts are actually asked, pulled from Slack threads, ticket queues and the meeting where someone says they will pull that number. Aim for two hundred. Sort them into three piles: already answered by an existing dashboard, answerable from data you hold, and unanswerable without data you do not have.
Only the middle pile is in scope, and it is usually smaller than the sponsor expects. This inventory becomes the scope document, the evaluation set and the adoption plan at the same time, which is why we will not begin a build without it. A ten-day Sprint Zero at $3,250 or ₹2,00,000, credited to the build, exists precisely to produce it when nobody internally has the time.
A term from the inventory that appears in fifty questions with three different meanings has just told you where stage two will hurt. Note those terms explicitly; they are the shortlist for the definitions that will need a decision from a person with the authority to make one.
Stage two: the semantic layer
A semantic layer is a machine-readable definition of your business vocabulary: which table holds orders, that revenue excludes cancellations and taxes, that an active customer has transacted in ninety days, and which joins are legal. Without it a language model guesses, and it guesses plausibly enough that nobody catches the error until a board meeting.
If you run dbt, much of this already exists as models, metrics and tests and should be reused rather than duplicated. If you do not, the layer is built as explicit metadata over the tables in scope. Either way it belongs to your data team afterwards, not to the querying system, because it will outlive it. The semantic layer: why text-to-SQL needs one covers the argument in detail.
This is the decision most costly to reverse. Teams who skip it to reach a demo faster spend the next quarter explaining why two answers to the same question disagree, and the fix is always to go back and build it.
Stage three: the architecture
The pipeline has six components. Each exists to prevent a specific failure, which is the useful way to explain it to a sponsor asking why it is not simply a prompt.
| Component | What it does | Failure it prevents |
|---|---|---|
| Question classifier | Decides whether the question is answerable, ambiguous or out of scope | Confident answers to questions the data cannot support |
| Schema retrieval | Selects the handful of relevant tables and columns from hundreds | Context overflow, and wrong-table joins on large schemas |
| Semantic layer lookup | Resolves business terms to columns, filters and metric definitions | Two departments receiving different revenue figures |
| SQL generation | Produces a query in the right dialect, with limits applied | Dialect errors and unbounded scans |
| Static validation | Parses the query, blocks writes, checks tables exist and permissions allow them | Data modification and cross-tenant reads |
| Execution and repair | Runs read-only against a replica; on error, retries once with the error message | A blank screen instead of an answer to a near-miss query |
| Explanation and citation | Shows the SQL, the tables used and the filters applied | Silent trust, which is worse than visible failure |
Three architectural rules travel with that table. Execute against a read replica with a read-only role, never the primary. Apply permissions inside the query through row-level rules rather than filtering results afterwards, as set out in row-level security for AI analytics. And always show the SQL, even to non-technical users; the analyst who checks it in week one is how the system earns trust for everyone else.
Stage four: evaluation
Build the evaluation set before the pipeline is finished. Sixty to a hundred questions from the inventory, each with a hand-written correct query and its correct result, run automatically on every change to the semantic layer, prompts or model. Score on execution match, meaning the result set is right, rather than on string similarity to the reference SQL, because there are many correct ways to write the same query.
Calibrate your expectations with published research rather than vendor slides. The BIRD benchmark evaluates text-to-SQL over large, messy, real-world databases and reports execution accuracy for leading systems well below what human experts achieve, which is a useful corrective to any pitch quoting a number in the high nineties. What 95% accuracy really means unpacks how those figures are usually constructed.
Track three numbers, not one: the share of questions answered correctly, the share correctly refused as out of scope, and the share answered wrongly with confidence. The third is the only one that damages trust, and driving it towards zero is worth sacrificing coverage for. A system that answers sixty per cent of questions and refuses the rest cleanly will be used daily; one that answers ninety per cent with five per cent silently wrong will be abandoned within a month of the first bad board number.
Stage five: launch and adoption
Launch to a named group of ten to twenty people who ask a lot of questions, not to the whole company. Run in shadow alongside the analysts for two or three weeks: the system answers, an analyst checks, and disagreements go into the eval set. Widen access only when the confidently-wrong rate is near zero on the questions that group actually asks. Keep the disagreement log afterwards, because it is the best backlog you will ever have for the semantic layer.
Put the system where the questions already happen. A separate console is an extra tab nobody opens; conversational analytics in Slack and Teams covers what that surface changes. Our Eazy Insights AI product is the packaged version of this pattern for teams who would rather configure than build.
Where this goes wrong
- Prompting the whole schema. Beyond about thirty tables this stops working, and schema retrieval becomes the core of the system rather than an optimisation.
- Skipping the read replica. A generated query against the primary is a production incident waiting for a Monday morning.
- Trusting a model to refuse. Out-of-scope detection belongs in a classifier with an explicit allow-list, not in a polite instruction.
- No repair loop. A single retry using the database's own error message recovers a meaningful share of failures at almost no cost.
- Hiding the SQL. Systems that show their working get corrected. Systems that do not get abandoned quietly.
- Ignoring dialect. A pipeline written for Postgres will not produce valid BigQuery, and MongoDB is a different exercise entirely; see text-to-SQL for MongoDB.
- Leaving the semantic layer with the vendor. It is your definition of revenue. It belongs in your repository.
When not to build this
If fewer than twenty people ask data questions and your warehouse has under thirty tables, well-built dashboards plus one analyst will beat this system on cost and on trust. If your definitions are genuinely contested between finance and operations, building a system on top of the disagreement will amplify it; resolve the definitions first, and you may find you no longer need the rest.
There is also a scale at which the honest recommendation is a packaged tool. A team living entirely inside one BI platform whose natural language feature covers the questions in the inventory should use it and spend the budget elsewhere. We say this on discovery calls more often than the category would suggest.
Timeline, team and price
A focused pilot over one warehouse runs five to seven weeks with an AI engineer, a data engineer and one of your analysts committing real time. A governed multi-source deployment with row-level security runs twelve to sixteen. Natural language data querying starts at $12,500 or ₹8,00,000 and runs to $38,500 or ₹25,60,000; a three-week AI POC Sprint at $6,250 or ₹4,00,000 proves the hardest thirty questions first. Full figures are on the pricing page and broken down in text to SQL solution cost in 2026.
A pre-build checklist
- Two hundred real questions, sorted into in-scope, already-answered and unanswerable
- An agreed owner for the semantic layer who is not the delivery team
- A read replica and a read-only role provisioned before the first sprint
- The row-level rules written down, per role, with someone who will sign them
- Sixty evaluation questions with hand-written correct SQL
- A named pilot group of frequent askers, with their manager's agreement on time
- A decision on surface: console, Slack, or embedded in your own product
- Query cost guards and row limits agreed with whoever pays the warehouse bill
Related reading
Natural-language reporting: turning questions into dashboards covers what happens after a query returns, and how long a text to SQL solution takes sets out a week-by-week schedule if you are planning a budget cycle around it.
Build the semantic layer and the evaluation set first, and the rest of a text to SQL solution is engineering you can schedule with confidence.
Frequently asked questions
How long does it take to implement a text to SQL solution?
▾
A focused pilot over one warehouse with ten to twenty curated tables takes five to seven weeks. A governed deployment across several sources with row-level security and audit logging takes twelve to sixteen. A three-week ProofRun against the hardest thirty questions is the usual way to de-risk the larger number.
Do you need a semantic layer for text to SQL?
▾
Yes, for anything beyond a demo. Without explicit definitions of revenue, active customer and the legal joins between tables, the model infers them from column names and produces answers that are plausible and wrong. If you already maintain dbt models and metrics, reuse them rather than building a second definition.
Is it safe to let an AI system run SQL on production data?
▾
Only with controls: a read-only role, execution against a replica rather than the primary, static validation that blocks writes and unknown tables, row-level rules enforced in the query, row limits and cost guards, and full logging of every query run. With those in place the risk profile is comparable to a BI tool.