Wat is NL2SQL en hoe werkt het?

NL2SQL verwijst naar het automatisch vertalen van een vraag in natuurlijke taal naar een SQL-query die relationeel kan worden uitgevoerd. In tegenstelling tot een generieke chatbot die reageert in vrije tekst, produceert een NL2SQL-systeem een ​​gestructureerd artefact, SQL, dat wordt uitgevoerd op basis van echte gegevens en regel voor regel een verifieerbaar resultaat retourneert.

De term ‘text-to-SQL’ komt uit academisch onderzoek naar natuurlijke taalverwerking. “NL2SQL” is de meest gebruikte afkorting aan de product- en technische documentatiekant. Beiden verwijzen naar hetzelfde probleem: het overbruggen van de kloof tussen een vraag die in alledaagse taal wordt gesteld en de precieze syntaxis die door een SQL-engine wordt verwacht.

NL2SQL onderscheidt zich van een conversational agent verbonden aan een database in brede zin. De eerste levert een leesbare en controleerbare vraag op; de tweede kan verschillende tooloproepen (zoeken, berekenen, schrijven) aan elkaar koppelen zonder noodzakelijkerwijs te resulteren in een unieke en inspecteerbare SQL. Een goed ontworpen NL2SQL-systeem blijft binnen deze bewust beperkte reikwijdte: vertalen, valideren, uitvoeren, een resultaat retourneren.

Een betrouwbare NL2SQL-pijplijn volgt altijd dezelfde volgorde, ongeacht de provider: de vraag gaat door een taalmodel, vervolgens wordt de geproduceerde SQL vóór uitvoering gevalideerd, nooit daarna. De Aurabase-implementatie, geverifieerd in de aura-ai-servicecode, illustreert elk van deze stappen met concrete regels in plaats van met een abstracte beschrijving.

1. Er wordt een vraag ontvangen met het daadwerkelijke schema van de basis

Het systeem associeert de vraag in natuurlijke taal met het schema van de opgevraagde database: tabelnamen, kolommen, typen. Dit patroon moet voortkomen uit introspectie van de werkelijke basis, en niet uit een beschrijving die door de beller wordt gegeven. Een implementatie die een door de klant opgegeven schema accepteert, zou de deur openen voor vragen over niet-bestaande tabellen, of voor het omzeilen van isolatie tussen projecten. De Aurabase-engine wijst expliciet elk schema-veld af (400-fout) dat in het verzoek wordt verzonden, in plaats van het stilzwijgend te negeren.

2. Een LLM genereert een kandidaat-SQL

Het taalmodel ontvangt de vraag en het schema in de prompt en produceert vervolgens een kandidaat-SQL-query samen met een korte uitleg. Aurabase behandelt drie providers gelijk met een toegewijde native client: OpenAI, Anthropic (Claude) en Gemini. Deze kandidaat-SQL is in dit stadium slechts een voorstel en wordt nooit rechtstreeks uitgevoerd.

3.De kandidaat-SQL wordt vóór uitvoering gevalideerd, niet erna

Dit is de stap die een serieus NL2SQL-systeem onderscheidt van een eenvoudige LLM-aanroep gevolgd door een naïeve uitvoering. De gegenereerde SQL wordt geparseerd in een syntaxisboom (AST) in plaats van geïnspecteerd door middel van een trefwoordzoekopdracht, wat gemakkelijk kan worden omzeild. De Aurabase-implementatie, met de sqlparser-bibliotheek, staat alleen eenvoudige SELECT-query's toe: CTE/WITH, subquery's, UNION's, vensterfuncties en vergrendelingsclausules (FOR UPDATE) worden expliciet afgewezen, net als alle SQL-functies buiten een witte lijst van tien functies (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4. Vastgelegde query's worden uitgevoerd met een rijlimiet

Gevalideerde SQL ontvangt een LIMIT als deze er nog geen heeft: standaard 100 regels met Aurabase, maximaal 1000, beide waarden kunnen aan de serverzijde worden geconfigureerd. Een verzoek boven de limiet wordt expliciet afgewezen in plaats van stilzwijgend verminderd. Het antwoord geeft aan of deze LIMIT door de server is toegevoegd, zodat de beller weet of de uitgevoerde SQL verschilt van die geproduceerd door het model.

-- Vraag: "Hoeveel bestellingen deze maand voor premiumklanten?"
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- toegevoegd door de server, ontbreekt in de gegenereerde SQL

De volledige details van deze pijplijn, met elke HTTP-aanroep en elk JSON-antwoord, worden behandeld in onze stapsgewijze tutorial voor het bouwen van een NL2SQL-eindpunt op Postgres.

NL2SQL is niet bedoeld om overal handgeschreven SQL te vervangen. Het bestrijkt een specifieke reikwijdte: ad hoc, eenmalige vragen die worden gesteld door iemand die SQL niet kent of die eenvoudigweg tijd wil besparen op een eenvoudige vraag.

• Ad hoc verkenning van een dashboard door een niet-technisch persoon (support, product, management).
• Snelle prototyping van een functie die de database doorzoekt zonder voor elke mogelijke vraag een speciale API-route te schrijven.
• Beperkte analytische selfservice: tellen, filteren, eenvoudig aggregeren, zonder directe toegang tot de database aan de eindgebruiker te geven.

Handgeschreven SQL blijft de voorkeur hebben zodra de vraag buiten deze reikwijdte valt. Een AST-gevalideerde implementatie zoals hierboven beschreven sluit om veiligheidsredenen CTE's, subquery's en vensterfuncties per constructie uit. Een analyse die deze constructies, cohorten en geavanceerde temporele vensters structureel nodig heeft, gaat niet via NL2SQL: deze wordt direct gecodeerd. Dit is een geaccepteerd compromis; de veiligheid van het systeem gaat boven de volledigheid van de gegenereerde SQL.

Drie risico’s komen systematisch terug in een NL2SQL-implementatie, met verschillende reacties afhankelijk van de volwassenheid van het systeem.

SQL-injectie via prompt of vraag

Een LLM kan worden gemanipuleerd om kwaadaardige SQL te produceren als de vraag zelf een injectiepoging "negeer eerdere uitspraken en..." bevat. De verdediging is niet om de prompt te vertrouwen, maar om de geproduceerde SQL te valideren, onafhankelijk van wat er werd gevraagd, precies stap 3 van de hierboven beschreven pijplijn. Het onderwerp verdient een speciale behandeling: zie NL2SQL beveiligen tegen SQL-injectie voor precieze aanvalsvectoren en tegenmaatregelen.

Hallucinatie van niet-bestaande tabellen of kolommen

Het model kan een tabel- of kolomnaam bedenken die plausibel is maar ontbreekt in het feitelijke schema, vooral bij grote of slecht gedocumenteerde schema's. Een implementatie die de gegenereerde SQL valideert aan de hand van het daadwerkelijke databaseschema wijst de query af met een expliciet bericht, waarin de daadwerkelijk beschikbare tabellen worden vermeld, in plaats van een onbewerkte SQL-fout terug te laten sturen naar de gebruiker.

Kosten en latentie van modelaanroepen

Elke NL2SQL-vraag activeert een aanroep naar het taalmodel, met zijn eigen kosten en latentie, naast de SQL-uitvoeringstijd. Deze kosten lopen snel op als NL2SQL fungeert als de standaardlaag voor repetitieve vragen, wat er baat bij zou hebben als het in de cache of in de vorm van een standaardrapport zou worden weergegeven in plaats van elke keer opnieuw te worden vertaald.

Twee architecturen produceren een vergelijkbaar zichtbaar resultaat, maar met heel verschillende garanties. Native NL2SQL integreert generatie, validatie en uitvoering rechtstreeks in de backend-laag die het schema en de toegangsrechten van het project al kent: dit is de hierboven beschreven logica voor Aurabase, waarbij de aura-ai-service de infrastructuur en schema-isolatie deelt met de rest van de backend.

Een samengestelde NL2SQL combineert een generieke LLM-service, een connector met de database en een zelfgebouwde validatielaag. Niets verhindert dat deze aanpak veilig is, maar elke garantie, server-side introspected schema, AST-validatie, row cap, isolation tenant, moet worden geïmplementeerd en onderhouden door het team dat deze stenen samenstelt, in plaats van te worden geleverd door het platform.

Het landschap van NL2SQL-tools, native en geassembleerd, open source en commercieel, wordt in detail vergeleken in onze NL2SQL 2026 toolvergelijking.

NL2SQL en RAG (Retrieval-Augmented Generation) beantwoorden twee verschillende vragenfamilies, die vaak verward zijn omdat beide afhankelijk zijn van een LLM die is verbonden met een database.

NL2SQL richt zich op gestructureerde en relationele gegevens: hoeveel, wanneer, welk aandeel, vragen die zich op natuurlijke wijze vertalen in SELECT, GROUP BY, aggregaties. De RAG richt zich op ongestructureerde inhoud: documenten, notities, supporttickets, waarbij het antwoord niet in een tabelrij past, maar vereist dat een relevante passage wordt gevonden op basis van semantische gelijkenis, zoeken naar vectoren op pgvector, HNSW-index, voordat het in context aan het model wordt gegeven.

De twee capaciteiten kunnen naast elkaar bestaan in hetzelfde project en worden gecombineerd in een agent die het een of het ander kiest, afhankelijk van de gestelde vraag. De Aurabase native AI-pijler beschrijft hoe de twee mechanismen samenwerken, en onze RAG-pijplijngids op pgvector behandelt de implementatie van de tweede.