Text-to-SQL Was a Joke. In 2026 It Isn't.

I spent a chunk of 2023 being a text-to-SQL skeptic, and I was right to be. The demos were beautiful and the reality was a model confidently joining two tables on columns that didn't share a meaning, returning a number, and presenting it like scripture. Wrong answers are worse than no answers, because someone pastes them into a board deck.

So I want to be careful here, because I'm about to say the thing the 2023 version of me would have rolled his eyes at: text-to-SQL works now. Not "works in the demo." Works in the boring, daily, I-stopped-thinking-about-it way.

What actually changed

It wasn't one thing. It was three, and only one of them is "the models got better."

The models did get better at SQL specifically. They've seen enormous amounts of it, and they're genuinely good at the syntax and the common patterns. But syntax was never the hard part. The hard part was always context.

The second change is that we stopped asking the model to guess the schema. In 2023 the workflow was basically "here's a question, write SQL," and the model had to hallucinate your table names. Now the schema gets handed to the model before it writes anything. It knows your tables are orders and line_items, not purchases and items, because it was told.

The third change is the one people undersell: we started giving the model the meaning, not just the shape. A column called status with values 1 through 4 is useless to a model that doesn't know 3 means "refunded." When you annotate that, the accuracy jump is not subtle. The model stops doing creative interpretation because it no longer has to.

The skeptic's real objection

The honest objection to text-to-SQL was never "the SQL is malformed." Modern models rarely produce SQL that doesn't run. The objection was "the SQL runs and returns the wrong number, and you can't tell."

That's still the risk. But it's a different risk than it was, because the failure mode moved. It used to fail on syntax and structure, which is invisible. Now it mostly fails on ambiguity, which is catchable. When two interpretations of "active users" exist, the model picks one. If you can see the query it wrote, you can see which one it picked, and you can correct it in plain English.

That's the whole trick, honestly. Text-to-SQL is trustworthy exactly to the degree that you can read what it wrote. A system that shows you the query is in a completely different trust category than one that hides it and hands you a number.

Where I'd still not trust it

I'm not going to pretend the line doesn't exist.

I wouldn't let it run unsupervised against a metric that someone is going to make a hiring or budget decision on without a human reading the query once. Not because it'll be wrong, but because "active users" means six things and you want to pin which one. Define that metric properly somewhere and the problem goes away, but until you do, read the SQL.

And I wouldn't let it write. Reading is forgiving; a wrong SELECT costs you a re-ask. A wrong UPDATE costs you a restore. The asymmetry is the whole reason I built QueryBear to be read-only at the parser level. Generate all the SQL you want. Just don't let it mutate anything on a guess.

The part that surprised me

The thing I didn't predict is how much the value comes from people who can't write SQL at all, versus people who can.

I assumed engineers would love it as a speed-up, and they do. But the bigger shift is the support rep, the ops person, the founder's non-technical cofounder, who now answers their own data question instead of dropping it in the engineering channel and waiting. The query was never the bottleneck for those people. The query was a wall. Text-to-SQL didn't make them faster at SQL. It removed the requirement that they know any.

That's the part I was wrong about in 2023. I thought the win was writing SQL faster. The win was not having to.