Most of us here have either built a text-to-SQL layer or been asked to. The demos always look great and the production version is the one that quietly returns the wrong number, so here is what actually separates the two.
The Schema Is The Feature, Not The Prompt
A natural language query layer is not a prompt engineering problem. When you connect a database, the model has to read the whole schema first: every table, every column, every data type, every foreign key. That is what lets it decide which tables to touch, which columns to filter on, and how to join them.
Skip that step and you still get SQL back. It runs, it returns rows, and it is wrong in a way nobody catches, because the join went through the wrong key. The systems that hold up are the ones that expose the generated SQL so a human can spot-check it, and that read relationships rather than guessing them from column names. There is a longer walkthrough of how that works in practice on asking your database questions in plain English.
Dirty Data Breaks It Before The Model Does
The second failure mode is upstream. Names stored three different ways, phone numbers in four formats, the same customer entered twice with a typo, blank fields where a required value should be. Your query is correct and your answer is still wrong, because COUNT DISTINCT on a column with fuzzy duplicates is not counting what you think.
This is the least glamorous part and it is where most of the accuracy lives. Fuzzy matching to find near-duplicate records, normalizing formats across the table, validating each field against the rules it should obey, flagging rows with missing required values instead of silently averaging around them. A practical rundown is in cleaning data with AI.
Let The Model Find What You Did Not Ask About
The third step is the one teams skip entirely. Every query you write encodes something you already suspected. Anomaly detection covers the rest: point anomalies like an order fifty times the average, contextual ones like revenue that is normal for a retailer and impossible for a two person consultancy, and collective ones where ten individually boring transactions land in the same minute.
That last category is the argument for running it at all, because no dashboard you would have thought to build catches it. Worth reading how AI anomaly detection actually runs if you are adding this to an existing stack.
The Takeaway
Plain English querying is not one feature, it is three: clean the data, give the model the real schema, then let it surface what your questions never covered. Ship it in that order and the demo and the production system finally agree with each other.
