Key takeaways
- RAG is designed for unstructured data, such as documents, handbooks and contracts.
- Text-to-SQL is designed for structured data in a database, such as revenue, stock and orders.
- With RAG, the model formulates the answer; with text-to-SQL, the database does the calculating and the model only writes the query.
- You can combine both by routing each question to the right technique.
- ENABLE uses only text-to-SQL; RAG on documents is not part of the platform.
Two ways to make AI work on your own data
A language model does not know your organisation. It does not know what your revenue was, what your purchasing terms say or which customer is behind on payments. To make AI useful on your own data, you have to give the model the right information at the moment the question is asked.
There are two common techniques for this. RAG (retrieval-augmented generation) retrieves relevant pieces of text from your documents. Text-to-SQL lets the model write a query on your database. A third route, further training a model on your own data (fine-tuning), is rarely the first choice for factual questions: a model does not reliably remember facts and has to be retrained after every change.
How RAG works
RAG is the usual technique behind an AI knowledge base in a company: an assistant that answers questions about the staff handbook, quality procedures, contracts or support articles.
With enterprise RAG, meaning RAG at the scale of an organisation, extra requirements come into play. Permissions per document must be carried over into the search index, so that nobody can use the AI to see a document they do not have access to. Outdated versions must be removed, source references must be accurate and you need to measure regularly whether the answers are correct. Also bear in mind that with RAG, text passages from your documents are sent to the language model. In broad terms, RAG works like this:
- Documents are split into smaller pieces of text (chunks).
- An embedding is created for each piece: a series of numbers that captures its meaning. These embeddings go into a vector database or search index.
- When a question comes in, the system looks for the pieces that resemble it most, often combined with ordinary keyword search.
- The pieces found are sent to the language model together with the question.
- The model formulates an answer and refers to the sources.
How text-to-SQL works
With text-to-SQL, the model receives the structure of your database: tables, columns, relationships and descriptions from a data dictionary. Based on that, it writes an SQL query, which the database runs. The answer to "What was the margin per product group?" therefore does not come from the language model, but from your own database.
This makes text-to-SQL strong at exactly the work language models are weak at: exact calculations across thousands or millions of rows. The result is verifiable, because you can read the query. The quality depends mainly on a clear data model and good metadata.
RAG and text-to-SQL compared
Both techniques give AI access to your own data, but they differ in almost everything: the type of data, what is sent to the model and how you check an answer.
| RAG | Text-to-SQL | |
|---|---|---|
| Type of data | Unstructured: documents, emails, wikis | Structured: tables in a database or data warehouse |
| Typical question | "What is our notice period for suppliers?" | "What was the margin per product group in the second quarter?" |
| What the model receives | Text passages from your documents and the question | Metadata (tables, columns) and the question |
| Who supplies the answer | The language model, based on the passages | The database; the model only writes the query |
| Verifiable through | Source references to the document | The query that was run |
| Biggest risk | Wrong or outdated passages, yet a confident answer | A query that is technically correct but answers a different question |
| Calculating across many rows | Weak | Strong |
| Access rights | Carried over per document or folder into the search index | Through database permissions, views or filters |
| Main preparation | Clean up documents, keep them current, record permissions | Get the data model and data dictionary in order |
When to choose RAG and when to choose text-to-SQL
The rule of thumb is simple: if the answer is in a text, choose RAG; if the answer has to be calculated from tables, choose text-to-SQL.
A common mistake is using RAG on exports of tables, such as a CSV with all orders in a vector database. The system then finds a handful of rows that resemble the question, and the model calculates with those. A total across all orders cannot be reliable that way. This is how to make the choice:
- Choose RAG for questions about policies, procedures, contracts, product documentation, quotes and minutes.
- Choose text-to-SQL for questions about revenue, margins, stock, orders, hours, planning and other KPIs.
- If in doubt, look at the type of answer: an explanation or quotation points to RAG, a number or table to text-to-SQL.
Combining RAG and text-to-SQL
Many questions in an organisation touch on both types of data. "Why did revenue fall in the North region?" calls for figures from the database and context from reports or notes. A combined solution sends each part of the question to the right technique: a routing layer decides whether a query is needed, a document search, or both.
RAG can also help text-to-SQL. With large databases containing hundreds of tables, you can first use RAG to look up the relevant table descriptions in the data dictionary, and only then let the model write a query. Complexity does increase, though: you have two security models, two sources of errors and a harder evaluation. So start with the technique that fits your most important questions.
What ENABLE does and does not do
ENABLE uses text-to-SQL. In the SQL Explorer, you ask a question in plain language; the AI writes SQL on your organisation's PostgreSQL data warehouse and ENABLE runs it read-only. The AI receives only metadata and the question, never rows of data.
ENABLE does not do RAG: the platform does not search documents, SharePoint sites or knowledge bases. If you also want to answer questions about documents, you need a separate RAG solution for that. You can, however, make saved queries available as a REST endpoint through the Data API, so that other systems can retrieve the same verified figures.