What is text-to-SQL?

Text-to-SQL is the technique that translates a natural-language question into an executable SQL query. You ask "how much did we sell in March versus last year?" and an LLM generates the query, runs it and returns the answer. It is the feature every executive asks for the moment they see generative AI: "I want to chat with my data", without waiting for a report or learning a BI tool. The model receives as context the table schema, column descriptions and examples of correct queries, and the more mature setups add guardrails such as read-only access and permissions inherited from the user before any query runs. The promise is appealing precisely because it removes the wait for a report or the need to learn a business intelligence tool, but the quality of the answer depends entirely on how clean and documented the underlying schema is: without that foundation, the model produces SQL that is syntactically correct but semantically arbitrary.

See also: Semantic layer · A layer that centralizes business definitions (metrics, dimensions) and serves them consistently to BI tools, analysts and now LLMs.

How it works

The model receives the question together with context about the database: the table schema, column descriptions, examples of correct queries and, in mature setups, the business definitions of the metrics. With that context it generates the SQL query, which runs on the warehouse or lakehouse; the result comes back to the user as a table, a chart or a sentence. Serious systems add guardrails: read-only access, permissions inherited from the user, query validation before execution. Data platforms (BigQuery, Snowflake, Databricks, Microsoft Fabric) and BI tools are integrating this capability natively, a sign that the direction is set.

An enterprise example

Uber's QueryGPT, born as a hackathon project in May 2023, is now in production handling about 1.2 million queries a month, cutting the average time to a correct query from 10 to 3 minutes, with 78% of active users reporting a real time saving. Its first version ran on a basic RAG: the vectorized question was matched via nearest-neighbor search against a small fixed set of tables and examples, and it worked well at small scale but lost accuracy as the number of tables grew, because plain vector similarity is not strong enough on its own. The current version first narrows the scope by business domain (an LLM classifies the intent), then selects candidate tables with human confirmation, then prunes irrelevant columns from the selected schemas, and only then assembles the final prompt with clean schemas, examples and business instructions. It is the practical proof of the point above: the quality jump did not come from a more powerful LLM, it came from narrowing the problem before generating the query.

Why it fails without foundations

The problem is not generating syntactically correct SQL: LLMs do that well. The problem is generating the right query. If "revenue" can mean three different things (with or without tax, with or without credit notes), if tables are named TBL_ORD_03 and nobody documented the columns, the model guesses: and a wrong answer delivered with confidence is worse than no answer, because it ends up in a decision. That is why text-to-SQL only works on top of a semantic layer that formalizes the metrics and a clean, documented schema. The practical reading for your business: "chatting with your data" is not a feature you buy, it is an architecture you build. The real work sits below the interface, and it is the same work that makes traditional BI trustworthy too.