Text-to-SQL

Text-to-SQL is a system's ability to convert a question asked in natural language (for example, "how much did we sell in Córdoba last month?") into a valid SQL query that the database can execute and answer. Instead of writing the technical statement (a SELECT with sums, filters and conditions by province), the user asks the way they would talk to a colleague and the system builds the code behind the scenes.

This translation is done by a large language model (LLM) that understands both the intent of the question and the structure of the tables. It is the piece behind conversational BI and the assistants that let you "talk to your data". In the Metrix analytics platform, Text-to-SQL is what connects a business question to the database to return a figure or a chart, without the user opening a technical tool.

The key is not just generating SQL that "runs", but generating correct SQL: SQL that points to the real tables and columns, respects the relationships and returns exactly what the person meant to ask.

How it works under the hood

When someone writes a question, the system does not send it "raw" to the model. First it gives the model schema context: which tables exist, which columns each one has, the data types and how they relate (for example, that the customer column in the orders table points to the identifier in the customers table). With that context and the question, the model drafts the SQL query. Then a good system validates that query before running it: it checks that the tables and columns exist, that the syntax is correct and, sometimes, runs a test version to catch errors. Only then does it execute the query and show the result.

Serious systems add a semantic layer between the question and the database. That layer defines the business in human terms: what "net revenue" means, what counts as an "active customer", how "margin" is calculated. Without it, the model has to guess the business logic by looking at column names, and that is where errors show up. With it, "quarterly sales" is always translated the same way, no matter who asks.

Why it matters for the business

The classic bottleneck in data analysis is not a lack of data; it is dependence on the technical team. The sales manager needs a number, opens a ticket with the data team, waits two days, gets the report, discovers a filter was missing and asks again. Text-to-SQL breaks that cycle: it enables real self-service analytics, where whoever needs the data gets it in seconds by writing in their own language. The analyst stops being a translator of requests and focuses on more complex problems.

A concrete example in Argentina: a consumer goods distributor with hundreds of SKUs and sales by channel. The trade marketing manager asks, "which products dropped more than 20% in the traditional channel versus the previous month?" Before, that was a multi-line query with joins and subqueries. With Text-to-SQL, the manager types the sentence, the system builds the SQL against the sales tables, runs it and returns the list. The speed of decision-making changes completely.

Common mistakes and limits

• Confusing Text-to-SQL with a search engine: it does not search text; it generates code that runs on structured data. The quality depends on how well the tables are defined.
• Expecting it to guess the business logic: if "billing" is calculated differently in finance than in sales, the model does not know that unless you define it in the semantic layer.
• Skipping validation: without a step that checks the query before running it, the system can invent columns that do not exist, a form of hallucination.
• Not restricting permissions: the generated SQL must run with the same permissions the user would have; never give it full access to the database.

How it differs from conversational BI and RAG

These three terms overlap, but they are not the same. This table separates them:

In short: Text-to-SQL is the engine, conversational BI is the product that uses it, and RAG solves a different problem (questions about documents, not about tables). For an exact numeric figure from the database, you want Text-to-SQL implemented well, with a clear schema, a semantic layer and a validation step.