How Accurate Is Text-to-SQL, Really? What the Benchmarks and Real Use Show in 2026

Text-to-SQL accuracy, the share of plain-English questions a system turns into correct SQL, typically lands between 70 and 90 percent on hard public benchmarks like Spider and BIRD, and noticeably higher on clean, well-modeled data with clear questions. The number is real but it is not the whole story. Accuracy depends far more on your schema, how you phrase the question, and whether you can see and verify the generated SQL than on which model is under the hood. A system that shows you the query it wrote is trustworthy at 85 percent; a black box that hides it is risky even at 95.

What the accuracy number actually measures

When a vendor or a paper quotes a text-to-SQL accuracy figure, it almost always means execution accuracy on a benchmark: given a natural-language question and a database schema, does the generated query return the same rows as a human-written reference query. Spider and BIRD are the two benchmarks people cite, and BIRD is deliberately harder because it uses messier, more realistic databases.

On these hard benchmarks, strong systems in 2026 sit in the 70 to 90 percent range. That sounds mediocre until you look at what the benchmarks throw at the model: cryptic column names, questions that require joining five tables, and schemas with no documentation. Those conditions are worse than most real business databases, which is why accuracy on your own well-organized warehouse is usually higher than the benchmark suggests. The benchmark is a stress test, not a forecast of your day-to-day experience.

The five things that actually move accuracy

The model matters less than most of these. If you want higher accuracy, this is the list that pays off, roughly in order of impact.

Notice that four of the five are things you control, not things the vendor controls. A team that names its columns sensibly and asks precise questions will get better results from an average model than a team with a cryptic schema gets from the best model. This is why we spend so much energy on the parts you can influence rather than chasing a bigger model.

Why simple questions are nearly always right

The failure rate is not spread evenly across questions. Simple, common questions, count of something, a sum grouped by one dimension, a filtered list, are answered correctly almost every time, because there is only one reasonable query to write. "How many signups last week" has essentially one correct SQL translation, and any competent system produces it.

Errors concentrate in ambiguous or complex questions. "Which customers are at risk" has no single SQL meaning until someone defines "at risk," so the system has to guess, and a guess is where accuracy drops. Likewise, a question that needs a self-join, a window function and three conditions has more places to go wrong than a single-table count. The practical takeaway: the ordinary questions that make up most of a team\'s daily work are exactly the ones text-to-SQL handles most reliably.

The verification loop is what makes accuracy usable

Here is the part people miss when they fixate on the headline number. An accuracy of 85 percent means roughly one in seven answers is wrong, and if you cannot tell which one, that is genuinely dangerous, because a confident wrong number is worse than no number. But that danger disappears the moment you can see the query.

When a system shows you the SQL it generated, a person who knows the data can glance at it and catch the mistake before anyone acts on it. The wrong join, the missing filter, the double-counting from a fan-out, these are obvious in the SQL even when the chart looks plausible. That is why we show the SQL on every single answer in Agentsql. The goal is not to pretend the model is perfect; it is to make every answer checkable so a human stays in the loop. For teams that treat data with the seriousness of an audit, being able to trace exactly how an answer was assembled is the difference between a tool you can rely on and a novelty.

How to get the most accurate results

You can push your real-world accuracy well above the benchmark with a few habits. None of them require technical skill.

• Name the metric, window and grouping. "Churn, last quarter, by plan" is unambiguous. "How is churn" is not.
• Refine in plain English instead of restarting. If the first answer is close but off, say what to change rather than rephrasing from scratch.
• Read the SQL on anything that matters. For a number that will end up in a board deck, the ten seconds it takes to check the query is the cheapest insurance you will ever buy.
• Fix the schema once, benefit forever. A clear column name or a documented relationship raises accuracy on every future question, not just the current one.

Do these and the difference between a 78 percent benchmark and your actual experience becomes large, because you are no longer asking the hard, ambiguous questions the benchmark measures. You are asking clear questions of clean data and checking the ones that count.

So can you trust it?

Yes, when two things are true: the system shows you the SQL, and you ask clear questions of reasonably modeled data. Under those conditions text-to-SQL is accurate enough to replace the days-long wait for an analyst on the ordinary questions that make up most of the work, and safe because every answer is verifiable. Trust it less when the query is hidden, the question is vague, or the schema is a mess, because those are the exact conditions where the errors hide.

Agentsql is built around that principle. It connects read-only to Postgres, MySQL, Snowflake or BigQuery, turns your plain-English question into SQL, runs it, and returns a chart, a table and a one-line answer, with the SQL shown every time so you can verify it. If you want the deeper mechanics, our text-to-SQL accuracy guide goes further, and the text-to-SQL feature page shows how it works in practice. See how it works, then ask your data a question and read the query it writes.