Local text-to-SQL: query your business database without sending data to the cloud

You have a database with your sales, orders and customers, and every week you need answers: "how many orders did we take last month, by region?" Today, you answer that question by writing SQL yourself, by putting it in the data team's queue, or by asking a cloud API. There is a fourth way: point a language model that runs on your hardware at the database schema, have it generate the query, run it in place, and get the result back. The data — revenue, addresses, margins — never leaves your infrastructure. That is local text-to-SQL, and it is the use case that makes the difference between renting an AI and owning one the most tangible.

What local text-to-SQL is

Text-to-SQL turns a natural-language question into an executable SQL query and returns the results. The local flow is a closed loop that stays inside your perimeter:

1. The question — you write it in English, the way you'd say it to a colleague.
2. The schema — the model receives table names, column names, types and descriptions. It does not receive the data.
3. The query — the model generates the SQL.
4. The execution — the query runs on your database, which can be a SQLite file of a few megabytes or an enterprise Postgres.
5. The answer — the results come back to you, ready for the report or the dashboard.

The point that matters for data control: in this design, the model sees only the schema and the question, never the rows. The computation happens on your database. No revenue figures, no client list, no margins travel through a provider's gateway. For anyone handling customer data, that is the difference between showing the cell grid and showing the sheets themselves.

Where it actually breaks: ambiguity

Here you need numbers, and the numbers come from a benchmark published in mid-October: ARCS (Ambiguity Resolution Corpus for SQL), the first text-to-SQL benchmark built on naturally occurring ambiguities over real-world databases, published by Megagon Labs (paper on arXiv). It contains 101 questions across 6 databases, with every ambiguity point annotated together with all possible interpretations and the correct query for each.

Take a question from the corpus, from a retail database: "Report the total revenue for each nation in 1995". It sounds routine. In the benchmark, it carries four distinct ambiguities:

• "total revenue" — gross or net, after discount?
• "for each nation" — the customer's nation or the supplier's?
• "in 1995" — order date, commitment date, ship date, or receipt date?
• include or exclude returns?

Every combination produces a different query, all plausible, all executable. ARCS reports that the top-performing closed model measured, gpt-6-sol, reaches only 51% end-to-end execution accuracy, and that no open-source model exceeds 27% (dataset).

Source	End-to-end execution accuracy on ambiguous questions
gpt-6-sol (closed)	51%
Best open-source model	27% (none exceed this threshold)

Two things stand out from this table. First: even with the best paid model, almost half the answers to realistic questions are wrong. Second: the gap between open and closed models is still wide, but the bottleneck is not the model's knowledge — it is the ambiguity of the question. The model guesses an interpretation instead of asking, and the failure does not bang: it returns a number that looks right. That is the defining trap of text-to-SQL, worse than an obvious error.

These are not lab contraptions. From the same corpus:

• "For each team that Marcus Williams played for…" — in a basketball database there are two players named Marcus Williams (born in 1985 and 1986): without asking, the model picks one.
• "Find posts with many related posts" — "many" is an undefined threshold. The model invents one.
• "Which events had a low budget remaining…" — "low" relative to what? Another threshold the model decides on its own.

The proposed fix: structured disambiguation

The paper introduces a paradigm worth understanding because it changes how you build the system: instead of letting the model hold a free-form dialogue, ambiguity is resolved through explicit, constrained interactions. The flow becomes:

1. The model identifies the ambiguous points in the question.
2. For each, it lists the plausible interpretations — the same annotations you find in ARCS.
3. You pick, from a closed set of options, the one you meant.
4. With the interpretation fixed, the model generates the query.

It is exactly how a good accountant works: he does not compute on the first impulse, he asks for the definition first — "gross or net revenue?" — and then does the math. The advantage over conversational clarification is practical: each clarification is short and multiple-choice, costs a few tokens, and the conversation does not balloon. And it works better with local models, which lose the thread more in long dialogues than in short, constrained exchanges.

Building it locally: schema-first and model limits

The pattern that works — and that mirrors the benchmark's own structure — is schema-first: the context you hand the model is the schema with column names and their descriptions, not the data. ARCS ships exactly that: column_meanings.json, a description per column (dataset). In your case, for a small database (up to a few dozen tables), describing the columns in one sentence each is enough; for a large one, you first need a filter that brings the model only the tables relevant to the question.

For the model, the selection criterion is the same one you use for RAG over your documents: memory and context, not "the smartest one". The context here is schema + question + a few examples, so context needs stay small; the right size is the one that fits your VRAM with headroom. A practical rule already covered in the hardware for local AI guide: at Q4, parameters count in gigabytes almost one-to-one (14B ≈ 7–8 GB of weights), then add headroom for context. A quantized 8–14B model is a sensible starting point for small databases; above 32B you enter a different hardware tier.

An honest note on the numbers: ARCS measures behavior on deliberately ambiguous questions and benchmark databases, not on your typical question. If your questions are simple ("count active customers", "sum of sales per month"), your local open model will do much better than the 27% cited. If they are rich in domain terms ("margin on promo products, excluding returns"), you will land closer to that number. The benchmark exists to explain the failure mechanism, not to predict your exact accuracy.

And the limits?

• Real-world accuracy is yours to measure. ARCS's 51% and 27% are on by-definition ambiguous questions. Build a set of ten questions where you know the right answer and measure there: it is the only number that counts.
• Implicit thresholds stay a hole. "Many", "low", "recent" have no value in the database. Structured disambiguation exposes them, but you are the one who has to set them.
• Generated SQL = executed code. Without a guardrail, a mistaken model can run a wrong query — rarely destructive (restrict execution to SELECT), but capable of returning numbers nobody questions because "the system produced them".
• Big schema = long context. Past roughly a hundred tables, the schema no longer fits a sensible context and you need a preliminary table-routing step.

Where to start today

The most concrete SMB use case local text-to-SQL offers today is not replacing the data team: it is giving people who cannot write SQL a first access to the numbers, with the data staying in-house. Start from a bounded database (sales, inventory, tickets), a cleanly described schema, and the disambiguation layer before you trust the answers. Treat the model like a junior analyst: fast, always available, but to be reviewed. Not like the accountant who signs the accounts. The entire difference between the two uses is there.

Sources

• ARCS: Towards Precise Text-to-SQL via Structured Disambiguation (arXiv 2610.09396)
• megagonlabs/arcs dataset on Hugging Face

In summary: local text-to-SQL closes the loop of the natural-language question inside your perimeter — schema and question to the model, execution on your database, results to you, data that does not travel. The ARCS benchmark shows the real bottleneck: the ambiguity of real questions, on which even closed models barely clear 50% and open ones stay under 27%. The answer is structured disambiguation — multiple-choice clarifications before the query — plus a test on your own questions, with the answers you know. Start small, measure on your own, and treat it like a junior analyst.

Article generated with AI