This is solving a problem few people have. They assume your table name, column names and relationships is confidential information. For most people such metadata is not confidential.
Long term, SQL will be phased out for new LLM-friendly query languages. The cost of AI generating tens of billions of queries per day creates a new incentive for rationality and efficiency that overcomes the human institutional weight of legacy languages. I'm working on such a language now: https://memelang.net/
Text-to-SQL is effectively pissing in the wind when we start looking at business value. The trouble is that it works just enough to be dangerous. It is a very interesting idea and can easily consume the resources of a technical team ~indefinitely. One obvious sign we are chasing shiny here is the German-to-SQL example. This is fun, but no one would actually pay for it.
I would classify Text-to-SQL as a Schedule I rabbit hole. It has some serious effects, but it otherwise has no acceptable level of value-add in most reasonable enterprises.
What is the human need to bash SQL at all costs? At its core, such a simple syntax, yet its so powerful at aggregating/manipulating tabular data and the like. Instead we’d rather declaratively say what we want in a more verbose/disjointed way… fascinating
I used to use SQL very extensively, but then I moved into different roles, and now I always have to look up its syntax, stuff like "how did HAVING work again?", "how do I search for a date two days before today". With Text-to-SQL I can express my query in natural language. Because I have a very solid understanding of relational data models I can craft my prompt very precisely, but without constantly having to go back to the documentation. So at least for casual users it's very helpful.
Sure, you have to phrase your question in a way that's a bit like trying to ask a very specific question of an annoying "Self-Diagnosed Internet Autistic" co-worker who can't tell the difference between being "precise" and being "a pedantic pain in the arse", but it is just text.
Oh you're upset because SQL isn't in German? Well there's no reason why you can't stick German into the lexer, set your columns up with German names, and get a query like
WAHLEN_SIE zeielen_id, benutzer_namen, eingetragen
AUS benutzern WO aktiviert = WAHR
SORTIEREN NACH registrierungs_datum;
people who can really speak German, ja ich weiss meine Deutsch is so schlect, geh schon ;-)
aren't programming languages like SQL designed to strike a quasi-optimal balance between precision and economy? that is to say, if I want to use plain English to specify some kind of data operations, the prompt will necessarily be more verbose and/or less specific than SQL statements. So why not just learn SQL properly? And then learn the domain-specific considerations of the source data as well as the domain-specific business requirements? Or am I missing something essential?
The original idea idea behind SQL was to create a language that looked like English and allowed regular users to express their queries in something that resembled natur
Al language. Naturally it has evolved into something far more complex, but maybe today with LLMs it can get back to its origin,
LLMs are getting pretty good at writing SQL. There is so much training material out there, and it is not that hard to validate the results. The real interesting question will be if they will be better at leveraging all the database specific dialects than tool like PowerBI. High-performance databases like Exasol often has a lot of specific features in their SQL dialects that generic tools and ORMs are not able to use, it will be interesting to see if LLMs can make that more accessible.
Instead of trying to get LLMs from zero to 100, which is impossible to do, you should concentrate on getting them from 75% to 95%.
The idea that someone who has no knowledge of the domain and no understanding of relational data modeling can chat “like to know really good um but don’t make any mistakes” with a GPU an uncover the mysteries of the universe is imbecilic.
But… someone what knows approximately what to do and sort of how to do it could work wonders — if we had LLMs trained on a corpus with specific rules.
I don’t know how to left join and what table I need to get the aggregate of sales in each region by date and price range, but I can describe it halfway and know how to check if each step is valid.
LLMs can do this. They’re trained on English, and they are able to weight definitive rules. But instead we throw a random text at a general purpose transformer.
Parsing a response of tokens into grammatical English is the most expensive computation (after the initial scraping and catalog). Instead of wasting all the cycles doing that against the sun total of GitHub, StackOverflow, Reddit, and Wikipedia, create a fuzzy match on a simplification a rigorous specification and train it on your data (just a few million tokens) to teach it that users have primary addresses and are associated to accounts that have regions and region X has roughly 10 times the sales volume of region y.
So someone intelligent in the matter with an understanding of logical rigor and a general idea of the data shape can actually become 10x more efficient, instead of trying to lift vibe coders to the level of Spakespearean monkeys, you could be turning mid-level devs into super analysts.
The problem is that often once it starts failing, it rarely recovers from an error, even given the exact error code.
In my dashboard, I added OpenRouter access, so you can quickly swap between models and see which one works best (for your desired accuracy/response time/pricing). Grok 4 Fast is one of the best overall.
15 comments
[ 2.5 ms ] story [ 34.2 ms ] threadI would classify Text-to-SQL as a Schedule I rabbit hole. It has some serious effects, but it otherwise has no acceptable level of value-add in most reasonable enterprises.
Sure, you have to phrase your question in a way that's a bit like trying to ask a very specific question of an annoying "Self-Diagnosed Internet Autistic" co-worker who can't tell the difference between being "precise" and being "a pedantic pain in the arse", but it is just text.
Oh you're upset because SQL isn't in German? Well there's no reason why you can't stick German into the lexer, set your columns up with German names, and get a query like
people who can really speak German, ja ich weiss meine Deutsch is so schlect, geh schon ;-)But really why would you bother?
LLMs are getting pretty good at writing SQL. There is so much training material out there, and it is not that hard to validate the results. The real interesting question will be if they will be better at leveraging all the database specific dialects than tool like PowerBI. High-performance databases like Exasol often has a lot of specific features in their SQL dialects that generic tools and ORMs are not able to use, it will be interesting to see if LLMs can make that more accessible.
Anyone selling you 99% accuracy can prove it there first.
But… someone what knows approximately what to do and sort of how to do it could work wonders — if we had LLMs trained on a corpus with specific rules.
I don’t know how to left join and what table I need to get the aggregate of sales in each region by date and price range, but I can describe it halfway and know how to check if each step is valid.
LLMs can do this. They’re trained on English, and they are able to weight definitive rules. But instead we throw a random text at a general purpose transformer.
Parsing a response of tokens into grammatical English is the most expensive computation (after the initial scraping and catalog). Instead of wasting all the cycles doing that against the sun total of GitHub, StackOverflow, Reddit, and Wikipedia, create a fuzzy match on a simplification a rigorous specification and train it on your data (just a few million tokens) to teach it that users have primary addresses and are associated to accounts that have regions and region X has roughly 10 times the sales volume of region y.
So someone intelligent in the matter with an understanding of logical rigor and a general idea of the data shape can actually become 10x more efficient, instead of trying to lift vibe coders to the level of Spakespearean monkeys, you could be turning mid-level devs into super analysts.
The problem is that often once it starts failing, it rarely recovers from an error, even given the exact error code.
In my dashboard, I added OpenRouter access, so you can quickly swap between models and see which one works best (for your desired accuracy/response time/pricing). Grok 4 Fast is one of the best overall.