RAG vs database queries for business data

RAG (retrieval-augmented generation) finds pieces of text that resemble the question and passes them to a language model to write an answer. A database query retrieves exactly the records that meet a condition and calculates with them precisely. For questions about documents, such as contracts, emails and policies, RAG is a good fit. For questions about figures, such as revenue, invoices, counts and differences, a query is the right approach, because RAG does not guarantee that all relevant data is included and a language model does not calculate reliably.

Two ways for AI to reach your data

A language model knows nothing about your business. To answer a question about your customers or contracts, it first needs the right information. There are two main routes for that.

How does RAG work?

1. Preparation. Documents are cut into chunks of a few paragraphs. Each chunk is converted into a series of numbers that captures its meaning, an embedding, and stored in a search index.
2. Search. When a question comes in, the question is also converted into an embedding. The system looks for the chunks whose meaning is closest to the question, for example the top ten.
3. Answer. Those ten chunks go to the language model together with the question, and the model turns them into an answer.

So RAG searches on meaning, not on exact words. A question about "price adjustment" also finds a passage about "indexation of the fee". That makes it strong for unstructured text.

How does a database query work?

1. Translation. The question is translated into an exact instruction, usually SQL: select all invoices for customer X in 2026, add up the amounts.
2. Execution. The database runs the instruction and returns exactly the records that meet it. Not the most similar ones, but all that qualify.
3. Explanation. A language model can put the result into plain language.

A query is exact and reproducible. The same question on the same data always gives the same answer. In an AI system, the query is often invoked through tool calling.

The difference in one example

Question: how much did we invoice customer X in 2026?

With RAG: the system finds the ten text chunks most similar to the question. Perhaps that is eight invoices for customer X, one invoice for a customer with a similar name and an email about an invoice. But customer X had 34 invoices in 2026. The model adds up the eight it received, or estimates. The answer sounds confident and is wrong.

With a query: SELECT SUM(amount) FROM invoices WHERE customer_id = 'X' AND year = 2026. The database adds up all 34. The answer is exact.

This is not an edge case. RAG is designed to find the most relevant chunks, not to guarantee completeness. For a sum, a count or a comparison, completeness is exactly what you need.

When should you use RAG, and when a query?

The rule of thumb: if the answer is in a field, use a query. If it is in text, use RAG. If you need to combine text and figures, first extract the agreements from the text into fields and then compare them with a query.

The combination: extraction and comparison

For revenue control, the combination is the most interesting. Many leaks sit precisely on the boundary: an agreement in text that never made it into invoicing.

Worked example: suppose you have 220 customer contracts as PDFs. You want to know which customers have an agreed minimum annual purchase that is not being invoiced.

Step 1, extraction. A language model reads each contract and extracts the agreement into fixed fields: customer number, minimum annual purchase in euros, period. This is not a RAG question but a targeted extraction per document. A sample is checked against the PDF.

Step 2, storage. The fields go into a table alongside the customer data.

Step 3, query. A query compares the minimum purchase with the revenue actually invoiced per customer. Say 14 customers are below their minimum, together EUR 71,000 short of the agreed volume, and none of them has received a supplementary invoice.

Step 4, review. For each customer, a person decides whether to invoke the minimum. That is a commercial choice.

The amounts are an example. The division of labour is the point: the language model reads, the database calculates, the person decides. The leak pattern itself is covered in revenue leakage between contract and invoice.

Where does RAG go wrong with business data?

Incompleteness. The top ten search results are not all the relevant ones. For documents that is often acceptable; for figures, never.

Outdated versions. The index holds both the old and the new contract. Both resemble the question. The model may get the old one.

Wrong context. A chunk of text is presented detached from its document. An amount from an appendix headed "Option B, not chosen" looks to the model like an agreement.

Access rights. A search index containing all the company's documents potentially gives anyone who can ask questions access to everything. Permissions must also apply in the index, see how to give AI access to business data.

Where do queries go wrong?

A wrong translation. If a language model writes the SQL, it can choose the wrong table or the wrong filter. A query that runs without error can still be wrong in substance. Narrow, predefined functions, such as revenue_per_customer(customer, period), are safer than free SQL.

Poor source data. An exact query on wrong data gives an exactly wrong answer. See what happens when AI uses the wrong business data.

Unclear definitions. "Revenue" can mean invoiced, paid or contractual. Without a fixed definition, the query answers a different question from the one asked.

Checklist: which approach does your AI application use?

1. Ask how figures are produced. Through a query or calculation, or by the model from retrieved text?
2. Ask a control question whose answer you know, such as a customer's revenue in a closed year, and compare it with the ledger.
3. Ask the same question twice. Do you get the same figure?
4. For document questions, ask for the source: which document, which passage?
5. Check that access rights apply to both the database and the search index.
6. Check whether old document versions are removed from the index or marked.

In a revenue intelligence system

A system that finds revenue leakage calculates with money. So the amounts must come from exact calculations on the source systems, not from text a language model summarises. RAG and extraction have their place in reading contracts, quotes and emails, where agreements sit that never ended up in a field. How those layers work together is described in how AI works within Revenue Intelligence and in AI architecture for Revenue Intelligence.

Frequently asked questions

Is RAG bad for business data?

No, but it is built for text. For contracts, policies and correspondence it is useful. For figures from your ledger or CRM, a query is more reliable.

Can a language model write SQL itself?

Yes, and it often works reasonably well. But a query that runs is not automatically a correct query. For recurring questions, predefined functions are safer than free SQL.

What is the difference between RAG and fine-tuning?

RAG gives the model relevant information at the moment of the question. Fine-tuning changes the model itself by training it further. For business data that keeps changing, fine-tuning is rarely the right choice. See fine-tuning vs RAG for business software.

Do I need a data warehouse for queries?

Not necessarily. A query can also run directly on a system's database or through the API of your CRM or accounting software. A central store becomes useful as soon as you want to combine data from several systems.