Document RAG vs. Text-to-SQL: Which Does Your Question Need?

The choice is not “unstructured AI versus structured AI” at the platform level. It is a routing decision for each question. A contract question and a revenue aggregation may appear in the same sentence, but they require different evidence paths.

What is document RAG?

Document retrieval-augmented generation, commonly called document RAG, finds relevant content in a document collection and supplies it to a model to produce an answer. For enterprise use, useful RAG should preserve more than plain text. It should retain page location, table structure, figures, and enough neighboring context for a reviewer to verify a claim.

DataFact’s Document Intelligence overview describes three distinct chunk types—text, table, and figure—and records page plus region coordinates for each chunk. That makes citations actionable rather than merely naming a file.

Good document RAG answers questions such as:

• What penalty applies after the third missed service-level target?
• Which safety checks must happen before assembly?
• What did the quarterly report attribute the margin decline to?
• Which version of the policy defines the current threshold?

These answers depend on language, document structure, version, and context.

What is text-to-SQL?

Text-to-SQL converts a natural-language question into a database query. In an enterprise workflow, the generator should work against maintained business semantics and execute within controlled permissions.

DataFact’s Data Analysis overview says generated SQL is visible, execution is read-only and bounded, and table- and row-level rules can be applied from the requester’s data role. It also describes versioned analysis-model snapshots for reproducing a historical answer under the definitions used at the time.

Text-to-SQL fits questions such as:

• What was gross margin by region last quarter?
• Which ten customers had the highest payment value?
• How many shipments missed the SLA in each month?
• Which cohort changed most after applying a different diagnostic criterion?

These answers require filtering, joining, grouping, and calculation over structured records.

Document RAG vs. text-to-SQL at a glance

Decision factor	Document RAG	Text-to-SQL
Primary source	PDFs, Office files, images, narrative reports	SQL datasets, schemas, warehouse tables
Core operation	Retrieve and interpret source passages or objects	Generate and execute a query
Typical evidence	Page, region, table, figure, quotation	SQL, result rows, metric definition
Main context	Wording, layout, version, surrounding clauses	Schema, relationships, grain, metrics, filters
Silent failure risk	Wrong chunk or flattened structure	Valid SQL with wrong business meaning
Best verification	Open the cited source in context	Inspect query, definitions, and result
Access control	Document and collection scope	Connection, table, and row scope

Neither column is inherently more accurate. Each fails when used for the wrong kind of question.

Why RAG is not the default answer for structured data

Putting exported database rows into a vector index can make them searchable, but search is not a substitute for aggregation. A question such as “What percentage of orders were late by region?” needs a defined denominator, exact filters, a grouping rule, and reproducible arithmetic.

Text similarity does not reliably execute that logic. It may retrieve representative rows while missing records that belong in the calculation. Text-to-SQL is a better fit when the source of truth is relational and the requested result is computed.

Conversely, SQL is not a substitute for document interpretation. A database may show a late shipment, but the applicable penalty tier may live only in a signed contract table.

The questions that require both

Cross-source questions join a written rule or narrative to actual data. Common patterns include:

Finance: reconcile the number and the explanation

The warehouse shows that margin fell. The quarterly review explains why. A complete answer needs the calculated variance, the narrative attribution, and citations to both.

Supply chain: apply signed terms to performance

Delivery records show missed targets. The supplier agreement defines service levels, grace periods, and penalties. The answer must retrieve the correct clause and query the relevant operational rows.

Compliance: test transactions against current policy

The policy document defines a threshold and exceptions. The database contains transactions. The analysis must use the current policy version, select the right cohort, and preserve an evidence trail.

DataFact’s public Data Agents page describes multi-source runs that plan sub-questions, retrieve from documents, query databases, surface conflicts, and return findings with citations. This establishes the product pattern, not universal workspace availability: the current Agent-type documentation does not enumerate a separate multi-source creation path. Confirm the exact configuration and availability in the intended workspace before rollout.

A routing framework for enterprise questions

Use these five questions before choosing an architecture:

1. Where does the authoritative fact live? If it is a clause, page, figure, or narrative statement, start with document retrieval. If it is a row-level fact or calculated metric, start with the database.
2. Must the answer calculate across many records? If yes, use a query engine rather than relying on semantic retrieval.
3. Does layout carry meaning? Merged headers, footnotes, and figures require structure-aware document parsing.
4. Does the asker have user-specific data scope? Database analysis needs execution-time permissions; document retrieval needs corresponding source access.
5. Does the question compare policy with performance? Route it to both channels and require the final answer to keep each claim attached to its evidence.

How to design a multi-source run

A robust run should make its work inspectable.

1. Decompose the request into document and database sub-questions.
2. Resolve ambiguity about period, geography, metric, or policy version.
3. Retrieve the relevant document objects with source locations.
4. Generate and execute bounded SQL using governed semantics and requester scope.
5. Compare the two result sets without smoothing over disagreement.
6. State which source supports each claim and identify unresolved conflicts.
7. Produce a durable output—narrative, tables, charts, and citations—that can be reviewed or re-run.

DataFact publicly describes adaptive multi-step planning, cross-channel corroboration, clarification, visible run steps, and outputs that can include data, charts, conclusions, and citations. Treat the visible trace as evidence to inspect, not proof that every hidden process is correct; the answer-production documentation makes the same qualification.

Evaluation scenarios to include

Test the boundary cases, not just the happy path:

• A document and table agree.
• They disagree because one source is stale.
• The question names an ambiguous metric.
• The relevant contract is not accessible to the requester.
• The database returns no rows because of user scope.
• A PDF table contains merged cells or footnotes.
• A valid query uses the wrong policy version.
• The answer has enough evidence for one claim but not another.

A successful system should not force a conclusion when the sources conflict or the available evidence is incomplete.

Frequently asked questions

Is text-to-SQL a type of RAG?

Not in the practical distinction used here. Both approaches may retrieve context, but text-to-SQL’s decisive operation is constructing and executing a relational query. Document RAG’s decisive operation is retrieving source content for interpretation.

Can I use RAG for Excel files?

It depends on the job. Narrative or small table lookups may work through document retrieval. Calculations over tabular worksheets need structure-aware analysis. DataFact distinguishes Documents (Lite) for retrieval from Documents (Excel) for tabular analysis in its agent-type documentation.

Which approach provides better citations?

They provide different evidence. Document RAG can point to a page or region. Text-to-SQL can show the query, result rows, and definitions. A cross-source answer should preserve both trails.

Do multi-source agents replace data modeling?

No. Database questions still need schemas, relationships, metric definitions, and access rules. Document retrieval also needs a curated corpus, parsing review, and source governance.

How does DataFact support both approaches?

DataFact presents document intelligence, governed data analysis, and data agents as connected product capabilities. Its public Demo also exposes examples of document Q&A, data analysis, AI Reports, and feedback tuning in a read-only sample space.

Choose by evidence, not by trend

Start with the shape of the answer you must defend. If it comes from a page, preserve the page. If it comes from a calculation, preserve the query. If it comes from both, do not collapse the trails into an unsupported summary.

See how DataFact connects documents and databases or try the public Demo.