What Is Text-to-SQL? Conversational BI Explained

Text-to-SQL is an AI technique that turns a question written in plain English into a SQL query, runs that query against a database, and returns the result as an answer. It lets people who do not write SQL get numbers from their own data. Conversational BI is the analytics product built on it.

Ask "what were sales in the North region last quarter?" and a text-to-SQL system works out which tables hold sales and regions, writes the query, checks it, runs it and shows you the figure, usually with a chart. This guide explains how it works, where it fails, and what to check before you put it in front of your team.

What is conversational BI?

Conversational BI (conversational business intelligence) is a way of using company data through questions and answers instead of fixed dashboards and reports. A user types or speaks a question, and the system replies with a number, a table, a chart and a short written explanation. Follow-up questions keep the context, so "now split that by product" works without repeating the first question.

Text-to-SQL is the engine. Conversational BI adds everything a business needs around it: a chat interface, user identity and permissions, charts, an audit log, and governed definitions of metrics. You will also see the terms natural language to SQL (NL2SQL), natural language query (NLQ) and "chat with your database". They describe the same core idea.

How text-to-SQL works, step by step

A production text-to-SQL system is a pipeline, not a single prompt. Each step removes a class of errors.

1. Schema understanding

The system needs to know what data exists: tables, columns, data types, keys and how tables join. Raw schemas are rarely enough. A column called amt_2 means nothing to a model, so good systems add descriptions, sample values and known relationships. For large databases, the system first retrieves only the tables relevant to the question, because sending hundreds of tables to the model hurts accuracy.

2. Semantic layer

The semantic layer defines business terms once: what counts as "revenue", "active customer" or "on-time delivery", which filters always apply, and which joins are correct. The model then maps the question to these defined metrics instead of guessing from raw columns. This is the single biggest factor in whether answers can be trusted, and it is also where most of the effort goes.

3. Query generation

An LLM receives the question, the relevant schema, the semantic definitions and often a few example question and SQL pairs from your own data. It writes a SQL query in your database's dialect, such as SQL Server, PostgreSQL, MySQL, Snowflake or BigQuery. If the question is ambiguous ("top customers" by revenue or by order count?), a well-built system asks a clarifying question instead of picking one silently.

4. Validation

Before anything runs, the generated SQL is checked. The parser confirms it is valid and read-only. The validator confirms it only touches allowed tables and columns, applies required filters and has a row limit. Some systems also run an EXPLAIN to catch very expensive queries. A query that fails is sent back to the model with the error, or refused.

5. Execution

The validated query runs with a read-only database role, under the identity of the person asking, with a timeout. Row-level security in the database decides which rows that person can see.

6. Answer and chart

The result comes back as rows. The system picks a suitable chart from the shape of the data (a trend over time, a comparison across categories, a share of a total), writes a short plain-English summary, and shows the SQL it ran so an analyst can check it. Showing the working is what turns "trust me" into "check me".

A text-to-SQL example

Question: "Which five customers had the highest revenue in the last quarter, and how many orders did each place?"

Given tables for customers and orders, and a semantic layer that defines revenue as completed order value net of refunds, a text-to-SQL system might produce:

SELECT c.customer_name,
       SUM(o.order_total - o.refund_amount) AS revenue,
       COUNT(o.order_id) AS orders
FROM orders o
JOIN customers c ON c.customer_id = o.customer_id
WHERE o.status = 'completed'
  AND o.order_date >= DATE_TRUNC('quarter', CURRENT_DATE) - INTERVAL '3 months'
  AND o.order_date <  DATE_TRUNC('quarter', CURRENT_DATE)
GROUP BY c.customer_name
ORDER BY revenue DESC
LIMIT 5;

Notice what the semantic layer contributed: the status = 'completed' filter and the refund subtraction. Without it, the model would likely sum every order and report a higher, wrong number that still looks plausible. For a full walkthrough of building this kind of system in code, see our engineers' guide on building an AI chatbot that queries relational databases in natural language.

Text-to-SQL vs RAG vs dashboards

These three are often confused. They answer different kinds of questions and work well together.

A common pattern combines them. "Why did margin drop in March?" needs the margin figure (text-to-SQL) and the explanation from board notes or emails (RAG). If your questions are mostly about documents, start with retrieval-augmented generation instead.

What text-to-SQL accuracy depends on

Published benchmark scores tell you little about how a system will do on your data. Accuracy on a real business database depends on four things.

• Schema quality. Clear table and column names, documented keys and consistent data types help the model. Cryptic names, duplicate tables and undocumented joins hurt it. Adding descriptions to the schema is often the cheapest accuracy gain available.
• The semantic layer. If "revenue" has three definitions across finance, sales and operations, the model cannot choose correctly. Agreeing on one definition per metric, and encoding it, removes a whole class of wrong answers.
• Guardrails. Validation, clarifying questions for ambiguous requests and a confidence signal stop the system from answering when it should not. An honest "I can't answer that reliably" is better than a confident wrong number.
• An evaluation set. Collect a set of real questions from your users with the correct SQL or the correct answer for each, including awkward multi-step ones. Run the system against it before launch and on every change to the prompt, model or semantic layer. This is the only way to know your accuracy, and to know whether a change made it better or worse.

The model matters less than people expect. Ambiguous data and missing business definitions cause more wrong answers than the LLM's SQL skills do. Choosing and testing the model is still part of the job, and our LLM development team benchmarks candidate models on the client's own question set.

Security: keeping text-to-SQL safe

Letting an AI write queries against live business data is safe only when the controls sit in the database, not in the prompt. A prompt that says "never delete data" is not a security control.

• Read-only roles. The system connects with a database user that can only run SELECT on approved schemas or views. Even a malicious or broken query cannot change data.
• Row-level security. Queries run with the asking user's identity, and the database filters rows by their permissions. A regional manager sees their region. Two people can ask the same question and correctly get different answers.
• Query limits. Row limits, timeouts and cost checks stop a single question from scanning a whole warehouse or slowing production systems. Many teams point text-to-SQL at a replica or warehouse rather than the transactional database.
• Allow-lists and masking. Only approved tables and columns are visible to the model. Sensitive fields such as salaries or personal identifiers are masked or excluded.
• Audit logs. Every question, generated query and result is recorded against a user, so you can answer an auditor or investigate a concern.

Text-to-SQL use cases by team

• Finance: spend against budget, overdue receivables, margin by product or region, month-on-month variances.
• Sales: pipeline by stage, top accounts, win rates by rep, deals slipping out of the quarter.
• Operations and supply chain: inventory levels, delayed orders, supplier on-time rates, stock-outs by warehouse.
• Projects and PMO: which projects are over budget, billed versus unbilled hours, resource utilisation.
• HR: headcount and attrition trends, open roles by department, with strict row-level rules.
• Customer support: ticket volumes, resolution times and backlog by category or channel.

The pattern is the same in each case: routine questions that used to become tickets in the data team's queue get answered directly, and analysts spend their time on the semantic layer and deeper analysis.

Build vs buy: text-to-SQL options

You can use text-to-SQL features inside a BI platform you already own, buy a dedicated product, or build a custom system.

• Features in BI platforms. Microsoft Power BI Copilot, Tableau's AI features, Looker with Gemini and Amazon Q in QuickSight add natural language questions to their own semantic models. They suit teams whose data already sits in that platform's models.
• Dedicated products. ThoughtSpot built its product around search and natural language analytics. Data platforms such as Snowflake (Cortex Analyst) and Databricks (AI/BI Genie) offer natural language querying over data stored with them.
• Custom builds. A custom system makes sense when data spans several databases, when you need the answers embedded in your own product or portal, when access rules are unusual, or when you want full control over the model, hosting and audit trail.

Questions to ask any option: Can it show the SQL it ran? Does it enforce your existing row-level security? How was accuracy measured, and on whose questions? What happens when it is unsure? Where does your data go when the model processes it?

A real example from VOCSO

We built a conversational BI platform for an enterprise client whose non-technical staff needed answers from internal SQL Server and enterprise databases without waiting for the technical team. Users ask questions in plain English. An LLM-based engine applies predefined business rules, generates and validates SQL, and returns results in visual and tabular form. The engine answered 739 natural-language queries across the pilot deployment. It picks one of four chart types (bar, donut, pie or scatter) from the shape of each result, and every answer comes with a chart, a written insight and an Excel export. That work became DataSense, our conversational BI product.

How VOCSO can help

VOCSO has been building software since 2009 and is certified to ISO/IEC 27001 and ISO 9001:2015. Our conversational BI and text-to-SQL development services start with a fixed-price proof of concept on one subject area of your real data, read-only, priced at $12K to $20K and taking about six weeks, with an accuracy check on your own questions and a costed plan for the full build. We work with clients in India and the US.

FAQ

What is text-to-SQL in simple terms?

Text-to-SQL is software that lets you ask a database a question in everyday language and get the answer back. An AI model translates your question into a SQL query, the query runs on your data, and the result is shown as a number, table or chart. It removes the need to know SQL or wait for an analyst to write the query.

Is text-to-SQL the same as conversational BI?

Not exactly. Text-to-SQL is the technique that converts a question into a database query. Conversational BI is the complete business product built around it, adding a chat interface, follow-up questions, charts, user permissions, governed metric definitions and audit logs. You can think of text-to-SQL as the engine and conversational BI as the car built around that engine.

How accurate is text-to-SQL?

It depends on your data more than on the model. Accuracy rises with clear schemas, a semantic layer that defines each business metric once, validation of every query, and clarifying questions for ambiguous requests. Public benchmark scores do not transfer to your database, so the reliable way to know is to test the system on a set of your own real questions before launch.

Is it safe to let an AI query my database?

Yes, when security is enforced by the database rather than by instructions to the model. Use a read-only database role, apply row-level security under the asking user's identity, allow-list the tables the model can see, set row limits and timeouts, and log every query. With those controls, a wrong or malicious query cannot change data or expose rows a user is not cleared to see.

What is the difference between text-to-SQL and RAG?

Text-to-SQL answers questions about structured data by generating and running SQL, so it is suited to totals, trends and rankings. RAG answers questions about documents by retrieving relevant passages and having an LLM respond from them. Many business questions need both, such as a revenue figure from the warehouse and the reason behind it from meeting notes or reports.

Should I use Power BI Copilot or build a custom text-to-SQL system?

Use the built-in feature of your BI platform if your data already lives in its semantic models and your questions stay within one tool. Consider a custom build when data spans several databases, when answers must be embedded in your own product, when access rules are complex, or when you need control over the model, hosting and audit trail.