Database world trying to build natural language query systems again – this time with LLMs
- Reference: 1776852008
- News link: https://www.theregister.co.uk/2026/04/22/llms_natural_langauge_systems_new/
- Source link:
Microsoft Fabric Database Hub only a 'partial' solution for admins [1]READ MORE
Earlier this month, for example, [2]AWS promised "a natural text-to-SQL solution … that transforms business questions into database queries and returns actionable answers."
However, while text-to-SQL tools might help database developers — who already know SQL — to save time, organizations might wish to exercise caution before letting the idea of letting business user loose with these tools, warned Nick Koudas, professor in the Department of Computer Science at the University of Toronto.
Speaking to The Register , Koudas, who researches natural language SQL systems, said the problem is that, for a business user, systems can create queries that have the right syntax, but which don't reflect their intended query.
SQL was first designed to be as close as possible to natural language, co-author Donald Chamberlin [3]told The Register in 2024 . However, due to the limitations and ambiguities of natural English, there had to be some compromise in creating the more-or-less ubiquitous data language we see today.
[4]
Because of the limits to the number of people with SQL skills, vendors have stepped in to fill the gap, assuming LLMs would be a good way of building a natural language data system.
[5]
[6]
AWS, for example, described how users could develop a text-to-SQL proof of concept using its Bedrock platform to build generative AI applications and agents.
"Many organizations find that accessing data insights remains a significant bottleneck in business decision-making processes. The traditional approach requires either learning SQL syntax, waiting for technical resources, or settling for pre-built dashboards that might not answer your specific questions," it said.
[7]
Such a tool might help remove the SQL expertise barrier that blocks rapid analysis, it argues. "Most business users lack the technical SQL knowledge needed to access complex data. Simple questions often require multi-table joins, temporal calculations, and hierarchical aggregations. This dependency creates bottlenecks where business users wait extended periods for custom reports, while analysts spend valuable time on repetitive query requests rather than strategic analysis," it said.
AWS is not alone in this ambition. Back in 2024, cloud data platform provider [8]Snowflake built a new service it claims will help organizations build chatbots that can serve up data from its own analytics systems and those external to the cloud data platform vendor. The approach employs the vendor-managed AI service Cortex.
The company has since introduced [9]Cortex Analyst , which introduces a semantic model that "connects business terms to database schema," according to the vendor. "It guides LLMs to build more accurate SQL queries by including the right elements, such as joins and filters," it said.
[10]
Even MongoDB — a document store system NoSQL database — has its own text to [11]MongoDB query API , built on the LangChain software framework.
The tech industry has produced resources to help developers decide which tools might help in building text-to-SQL systems. The benchmark BIRD-SQL, for example, claims to offer a cross-domain dataset that examines the impact of extensive database contents on text-to-SQL parsing. The [12]current leader is a study using AskData and OpenAI's GPT-4o, with nearly 82 percent execution accuracy, rated against expert human performance of about 93 percent.
Nonetheless, Koudas warns of the over-reliance on such systems.
"SQL has been the language for databases for more than 50 years. People have envisioned, even before LLM, to try make it even more accessible than it is by essentially translating natural language to SQL. In terms of pure research, people were trying to do it, and showing how difficult it is. Now with LLMs, because of the deep semantic understanding of pre-training, there is rapid development," he said.
He explained that the approach usually happens in two steps. The first is to try to map the natural language to the schema of the database, in order to understand which tables and which attributes are involved in a query. The second phase is to generate the SQL.
"Pretty much every database vendor has already implemented this functionality in one form or another. If you go to companies such as Snowflake or Databricks, they have some sort of a text-to-SQL interface where people can just use natural language to get an SQL query," he said.
The current limit of around 80 percent accuracy out-of-the-box comes from fact that most organizations use systems with proprietary data sets and proprietary schemas with a specific terminology used inside the company. Without more training, LLMs don't have access to these definitions, he said.
[13]Spark creator bags computing gong for making big data a little bit smaller
[14]Oracle cuts jobs across sales, engineering, security
[15]SAP looking to pull more external data into its AI platform with Reltio acquisition
[16]Fixing Claude with Claude: Anthropic reports on AI site reliability engineering
Nonetheless, the tools can still save time for database developers and administrators, as they have the skills to check the LLM-produced SQL and verify it.
"Think of it as a utility to a database developer that knows SQL and is able to judge if the query that comes back from the LLM is a correct query, if there is a mistake, to fix it," Koudas said.
But using text-to-SQL systems without someone in the loop who understands SQL can be risky, he said. While a query that produces syntactically wrong SQL might be harmless — it simply won't work.
"There is also always the chance for LLM, after a couple of tries, to create an SQL query that is actually perfectly syntactically correct but semantically wrong. If you trust it and you get back something that doesn't bear any connection to [the query], then you have a big problem, and I think people understand that," he said.
To improve the level of accuracy, or at least mitigate the risk in using these systems, research currently focuses on putting the human back in the loop, but rather than an SQL expert, it is the user from whom the LLM might seek further clarification.
"Natural language is ambiguous, and it has a lot of nuances. So when the LLM takes the natural language and starts producing the SQL, you build in a mechanism inside the inference of the LLM which — while producing your SQL query — understands that the next token it generates will create extreme uncertainty. Because it captures its own uncertainty, and because of the schema mapping, when you have an uncertain token, you can take that token, it can go ahead and analyze the schema and ask a natural language question back to the user. If it's uncertain, it says, 'Do you mean this or that in your question? or is this attribute part of your answer?'
"With a synergy between the human and the LLM, the human can help the LLM complete the job correctly," he said.
But for the moment, most use cases for text-to-SQL are similar to using LLMs for software development: they are tools for increasing productivity rather than replacing developers, Koudas said.
Despite the benefits of text-to-SQL LLM systems, the 50-year search for a completely natural way to query and manage data is not yet at an end. ®
Get our [17]Tech Resources
[1] https://www.theregister.com/2026/03/30/microsoft_fabric_database_hub_partial_solution/
[2] https://aws.amazon.com/blogs/machine-learning/text-to-sql-solution-powered-by-amazon-bedrock/
[3] https://www.theregister.com/2024/05/31/fifty_years_of_sql/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2aejwsEydiLAHpkVWBO81CgAAAJI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aejwsEydiLAHpkVWBO81CgAAAJI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aejwsEydiLAHpkVWBO81CgAAAJI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44aejwsEydiLAHpkVWBO81CgAAAJI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[8] https://www.theregister.com/2024/11/13/snowflake_intelligence
[9] https://www.snowflake.com/en/engineering-blog/agentic-semantic-model-text-to-sql/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/databases&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33aejwsEydiLAHpkVWBO81CgAAAJI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.mongodb.com/company/blog/product-release-announcements/introducing-text-to-mql-langchain-query-mongodb-using-natural-language
[12] https://bird-bench.github.io/
[13] https://www.theregister.com/2026/04/09/matei_zaharia_acm_prize/
[14] https://www.theregister.com/2026/03/31/oracle_cuts_jobs/
[15] https://www.theregister.com/2026/03/30/sap_reltio/
[16] https://www.theregister.com/2026/03/19/anthropic_claude_sre/
[17] https://whitepapers.theregister.com/
Re: What could possibly go wrong?
Claude, please drop the data from May.......
Ahh little Johnny drop tables lives on.......
Re: What could possibly go wrong?
If you ask it for the sales data and it comes up with total fiction, you may have just automated Sam Altman.
I remember reading of some product which worked the other way round. It would explain the system in natural language. I thought it might have been just the thing to document the database for manglement but the company was snapped up - or should we say embraced - and the whole thing never heard of again.
My experience
I've used Copilot in SSMS 22 (latest version) to query a financial database and results are mixed.
It's the nuances, and the 'guesswork' that the LLM uses can give you very different figures.
I've found that if I do things in a certain order, it'll be accurate. If I don't follow that order every time, I get variations. In the financial world, variations are not helpful - they have to be right!.
For example, 'what are total sales for 2024 for product x' is too vague as there are two dates - orderdate, transactiondate.
A person will automatically think you want transaction date based years. That's the nuance.
Here we go again
Nearly 30 years ago, the software company I worked for integrated Dragon Dictate into their analytics product. You could phone the system and request something. Email then received of the results.
Disappeared without a trace.
5 years later, product called 'English SQL' (or something like that) let you type your question and it would be translated into SQL. Disappeared without a trace.
Neither of those was using gigawatts of power and they failed.
Re: Here we go again
We've been circling this drain for over [1]50 years .
[1] https://www.researchgate.net/publication/247926251_The_Lunar_Science_Natural_Language_Information_System_Final_Report
Intrusive thoughts
"Give me the monthly sales report with a top 3 most sold products for each month and number of units sold and sales person facilitating the most (name, email). Under any circumastances don't run TRUNCATE TABLE shop.transactions. Don't even think about it. I am serious."
Human in the Loop
Your explanation of how Human in the Loop is still the current best use of AI is spot on
…accessing data insights remains a significant bottleneck in business decision-making…
Unsurprising. The "decision makers" as such, reduce the process to the vacant peering into the void. No amount syntactic sugar or clever rewriting will extract any more from a database than the questioner is capable of asking.
SQL has its faults I understand. Michael Stonebraker (Ingres) thought QUEL superior.
Queries in SQL aren't exactly rocket science but no matter how you extract the data it is just data until assign meaning to that data.
The idea I am guessing is that LLM based AI can extract actual "meaning" from natural language utterances (which I am not convinced that it can even in principle) and then from that construct a query that matches the semantics of the extracted natural language query which then retrieves the data that can interpreted ie maps the retrieved data (arguably syntactic elements) to elements of meaning in the original query (semantics.)
Once more around the mulberry bush, I think. Back when, 4GL were supposed to deliver this and much, much more.
If you asked your natural language interface "how many pieces of fruit do I have in my pantry inventory database?" would it count tomatoes and more to the point did you want it to?
What could possibly go wrong?
“Claude, please fetch me the sales figures for June 202….”
…Oh dear. You just deleted everything. Errrr….