You Can Now Ask Your Database Anything in Plain English.
Quick Reads
- AWS, Snowflake, and MongoDB are all now shipping text-to-SQL tools powered by LLMs that let anyone query databases using plain English instead of SQL code
- The best systems currently hit about 82 per cent accuracy, against expert human performance of 93 per cent, meaning roughly one in five queries may silently return the wrong answer.
- The dangerous failure mode is not a broken query but one that runs perfectly, returns data confidently, and is entirely semantically wrong, with no error to alert the user.
- Experts say these tools are best treated as productivity aids for people who already know SQL, not replacements for that expertise at the general business user level.
The idea of asking a database a question in plain English and getting a straight answer is about 50 years old. Every decade or so, the technology press announces it has finally arrived. It was reported on April 22, 2026, that this time, the underlying technology has genuinely improved. The caveats, though, matter more than the headlines suggest.
AWS has built a text-to-SQL solution through its Bedrock platform aimed squarely at removing the SQL expertise bottleneck that slows business analysis. Most business users cannot write SQL. Analysts spend too much time fielding repetitive query requests. Dashboards rarely answer the exact question someone has today. A natural language interface, in theory, eliminates all of that. Analyst goes a step further, building a semantic model that maps company-specific business terminology to the database schema before the SQL generation even begins. MongoDB has its own version built on the LangChain framework. The consensus across the industry is clear: every major database vendor now has some version of this working, or is building one.
The benchmark that honestly tracks progress is BIRD-SQL, a cross-domain dataset testing text-to-SQL accuracy against real database conditions. The current leader sits at around 82 per cent execution accuracy. Expert human performance on the same tasks runs at about 93 per cent. That gap has a specific character that Nick Koudas, a professor at the University of Toronto who researches natural language SQL systems, explained to The Register in plain terms worth quoting directly. The problem is not the queries that fail. It is the queries that succeed.
A syntactically broken SQL query simply will not run. You will know something went wrong immediately. But an LLM, after a few attempts, can generate a query that is perfectly syntactically correct and completely semantically wrong. It runs. It returns data. It gives you a confident-looking answer to a question you did not actually ask. Without someone who knows SQL in the loop to catch it, you can act on bad data without any signal that something has gone wrong.
The accuracy gap between what LLMs produce and what a company’s specific data actually looks like is mostly a training data problem. Most organisations have proprietary database schemas with internal naming conventions, custom terminology, and relationship structures that no pre-training corpus ever covered. Without fine-tuning or careful contextual setup, the LLM is guessing at what your company means by certain table names or column definitions, and guessing confidently.
Current research is addressing this through what Koudas describes as human-in-the-loop clarification, building systems where the LLM recognises its own uncertainty mid-query, pauses, and asks the user a targeted follow-up question in natural language before generating the SQL. That back-and-forth narrows ambiguity and improves output quality without requiring the user to understand the underlying query language. It is a meaningful step forward, even if it adds friction to the experience that was supposed to be frictionless.
The practical guidance from researchers building these systems lands in the same place: treat text-to-SQL as a productivity tool for people who can verify the output, not a way to open database access to everyone and walk away. Used by someone who already understands SQL, it saves real time by handling the repetitive parts of query construction. Used by someone who cannot read the SQL it produces, it creates a quiet, confident data error that may not surface until a decision has already been made on it. SQL has been the language of databases for 50 years for good reason. Replacing it entirely is still a harder problem than any vendor press release currently suggests.
