"Just ask the database in English" is one of those AI promises that sounds trivial and turns out to be quietly hard. The task even has a name, Text-to-SQL or NL2SQL: take a question like "who were our top five customers by revenue last quarter" and produce the exact SQL that answers it. The trap is that a model can generate SQL that runs perfectly and returns the wrong number, and unless someone knows the data cold, nobody catches it.
A 2025 paper, SQL-of-Thought, tackles this well, and the core idea is worth understanding even if you never read the paper, because it applies to a lot more than SQL. In short: stop asking the model to write the query in one leap, make it plan first, and give it a structured way to correct itself.
Why plain NL2SQL keeps getting it wrong
The naive approach is to hand the model your database schema and the question and hope for the best. It works for toy queries and falls apart on real ones, for a few predictable reasons.
- It guesses at the schema. Your question says "revenue" and your database has
net_amountin atransactionstable joined toaccounts. The model has to bridge that gap, and it often bridges it wrong. - It skips the reasoning. A hard query needs a plan: which tables, which joins, which filters, in what order. Ask for the SQL directly and the model does that reasoning implicitly, badly, and invisibly.
- It can't tell it failed. Even when a query errors, the usual fix is "run it, see the error, try again." That catches crashes. It does not catch queries that run fine and answer the wrong question.
That last category is the dangerous one. A crash is obvious. A confidently wrong number in a board deck is not.
The SQL-of-Thought approach: plan, then fix on purpose
Instead of one model doing everything, SQL-of-Thought breaks the job into a chain of specialised steps, each doing one thing well. Think of it as an assembly line rather than a single craftsperson trying to do the whole thing in their head.
The pipeline runs in five stages:
- Schema linking. First, connect the words in the question to the actual tables and columns. "Revenue" gets mapped to the real column, "last quarter" to the real date logic. Get this right and everything downstream gets easier.
- Subproblem identification. Break a complex request into smaller pieces. A question that needs a filter, a join, a group-by, and a ranking becomes four manageable parts instead of one tangle.
- Query plan generation. Reason out the steps in plain language before writing any SQL. This is the "thought" in SQL-of-Thought: a written plan of attack that a human could read and sanity-check.
- SQL generation. Only now does the model write the actual query, translating the plan it just made into code. Because the thinking already happened, this step is mostly mechanical.
- Guided correction loop. If something is wrong, fix it deliberately.
That last stage is the real contribution, so it's worth slowing down on.
The clever bit: guided error correction
Most systems that self-correct do it by execution. Run the query, and if it throws an error, feed the error back and try again. SQL-of-Thought does something smarter. It uses a taxonomy of error types, a structured catalogue of the ways SQL commonly goes wrong, and when it detects a problem it matches it to a category and applies reasoning specific to that kind of mistake.
The paper calls this taxonomy-guided dynamic error modification, informed by in-context learning. In plainer terms: instead of blindly retrying, the system diagnoses what kind of mistake it made and fixes it the way you'd fix that specific class of bug. It's the difference between "that didn't work, let me try something else" and "ah, that's a wrong-join-condition error, here's how those get fixed."
The result, according to the paper, is state-of-the-art performance on Spider, the standard benchmark for Text-to-SQL, and its harder variants. And it was accepted at a NeurIPS 2025 workshop, so it's real research, not a blog claim.
Why this matters beyond SQL
Here's the part worth taking away even if you never build a Text-to-SQL system. SQL-of-Thought is a case study in three ideas that keep showing up in the best AI systems of 2026:
| Idea | What it means | Why it helps |
|---|---|---|
| Decompose the task | Split one hard job into specialised steps | Each step is easier and easier to check |
| Plan before you produce | Reason in plain language first, then generate | The thinking is visible and correctable |
| Structured self-correction | Diagnose the type of error, then fix it | Beats blind retrying, catches subtle failures |
You can see the same pattern in spec-driven development, where you write the plan before the code, and in agentic systems generally. Break the problem down, make the reasoning explicit, and give the model a real method for fixing itself rather than hoping a retry lands.
If you want to try NL2SQL in your own business
Text-to-SQL is genuinely useful. Letting a finance lead or an operations manager ask the database a question in English, and get a trustworthy answer, removes a real bottleneck. But do it with eyes open.
- Invest in schema linking. The single biggest quality lever is helping the model understand your data. Clear table and column names, a data dictionary, and good descriptions do more than any prompt trick. This is where a semantic layer earns its keep, because it hands the model trustworthy definitions instead of raw tables.
- Make the plan reviewable. Systems that show their reasoning let a human catch a wrong assumption before it becomes a wrong number.
- Keep a human on high-stakes answers. For anything feeding a real decision, the query and its logic should be checkable, not just its output.
The lesson SQL-of-Thought teaches is bigger than databases. When you want an AI to get something exactly right, don't ask for the answer directly. Make it think in steps you can inspect, and give it a real method to fix itself. That's how you turn an impressive demo into something you'd actually trust with your numbers.