Was ist NL2SQL und wie funktioniert es?

NL2SQL bezieht sich auf die automatische Übersetzung einer Frage in natürlicher Sprache in eine SQL-Abfrage, die auf relationaler Basis ausgeführt werden kann. Im Gegensatz zu einem generischen Chatbot, der in Freitext antwortet, erzeugt ein NL2SQL-System ein strukturiertes Artefakt, SQL, das anhand realer Daten ausgeführt wird und Zeile für Zeile ein überprüfbares Ergebnis zurückgibt.

Der Begriff „Text-to-SQL“ stammt aus der akademischen Forschung zur Verarbeitung natürlicher Sprache. „NL2SQL“ ist die am häufigsten verwendete Abkürzung auf der Seite der Produkt- und technischen Dokumentation. Beide beziehen sich auf dasselbe Problem: die Lücke zwischen einer in der Alltagssprache gestellten Frage und der präzisen Syntax zu schließen, die von einer SQL-Engine erwartet wird.

NL2SQL unterscheidet sich im weitesten Sinne von einem Konversationsagenten, der mit einer Datenbank verbunden ist. Die erste erzeugt eine lesbare und überprüfbare Abfrage; Der zweite kann mehrere Tool-Aufrufe (Suche, Berechnung, Schreiben) verketten, ohne dass dies zwangsläufig zu einem eindeutigen und überprüfbaren SQL führt. Ein richtig gestaltetes NL2SQL-System bleibt innerhalb dieses bewusst eingeschränkten Bereichs: übersetzen, validieren, ausführen, ein Ergebnis zurückgeben.

Eine zuverlässige NL2SQL-Pipeline folgt immer der gleichen Reihenfolge, unabhängig vom Anbieter: Die Frage durchläuft ein Sprachmodell, dann wird das erzeugte SQL vor der Ausführung validiert, niemals danach. Die im Servicecode aura-aiverifizierte Aurabase-Implementierung veranschaulicht jeden dieser Schritte mit konkreten Regeln und nicht mit einer abstrakten Beschreibung.

1. Die Frage wird mit dem tatsächlichen Schaltplan der Basis beantwortet

Das System verknüpft die Frage in natürlicher Sprache mit dem Schema der abgefragten Datenbank: Tabellennamen, Spalten, Typen. Dieses Muster muss aus einer Selbstbeobachtung der tatsächlichen Grundlage stammen und nicht aus einer Beschreibung des Anrufers. Eine Implementierung, die ein vom Kunden deklariertes Schema akzeptiert, würde die Tür zu Fragen zu nicht vorhandenen Tabellen oder zur Umgehung der Isolation zwischen Projekten öffnen. Die Aurabase-Engine lehnt jedes in der Anfrage gesendete schema-Feld explizit ab (Fehler 400), anstatt es stillschweigend zu ignorieren.

2. Ein LLM generiert einen Kandidaten-SQL

Das Sprachmodell empfängt die Frage und das Schema in seiner Eingabeaufforderung und erstellt dann eine Kandidaten-SQL-Abfrage zusammen mit einer kurzen Erklärung. Aurabase behandelt drei Anbieter gleichberechtigt mit einem dedizierten nativen Client: OpenAI, Anthropic (Claude) und Gemini. Dieses Kandidaten-SQL ist zu diesem Zeitpunkt nur ein Vorschlag, der nie direkt ausgeführt wird.

3. Das Kandidaten-SQL wird vor der Ausführung validiert, nicht danach

Dies ist der Schritt, der ein seriöses NL2SQL-System von einem einfachen LLM-Aufruf mit anschließender naiver Ausführung unterscheidet. Das generierte SQL wird in einen Syntaxbaum (AST) geparst und nicht durch eine Schlüsselwortsuche überprüft, die leicht umgangen werden kann. Die Aurabase-Implementierung mit der Bibliothek sqlparsererlaubt nur einfache SELECT-Abfragen: CTE/WITH, Unterabfragen, UNIONs, Fensterfunktionen und Sperrklauseln (FOR UPDATE) werden explizit abgelehnt, ebenso wie alle SQL-Funktionen außerhalb einer Whitelist von zehn Funktionen (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4. Die festgeschriebene Abfrage wird mit einer Zeilenbegrenzung ausgeführt

Validiertes SQL erhält ein LIMIT, wenn es noch keins hat: 100 Zeilen standardmäßig mit Aurabase, maximal 1000, beide Werte auf der Serverseite konfigurierbar. Eine Anfrage, die über die Obergrenze hinausgeht, wird ausdrücklich abgelehnt und nicht stillschweigend reduziert. Die Antwort gibt an, ob dieser LIMIT vom Server hinzugefügt wurde, sodass der Aufrufer weiß, ob sich die ausgeführte SQL von der vom Modell erzeugten unterscheidet.

-- Frage: „Wie viele Bestellungen diesen Monat für Premium-Kunden?“
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- Vom Server hinzugefügt, fehlt im generierten SQL

Die vollständigen Details dieser Pipeline, mit jedem HTTP-Aufruf und jeder JSON-Antwort, werden in unserem Schritt-für-Schritt-Tutorial zum Erstellen eines NL2SQL-Endpunkts auf Postgresbehandelt.

NL2SQL soll nicht überall handgeschriebenes SQL ersetzen. Es deckt einen bestimmten Bereich ab: Ad-hoc-, einmalige Fragen, die von jemandem gestellt werden, der sich nicht mit SQL auskennt oder einfach bei einer einfachen Abfrage Zeit sparen möchte.

• Ad-hoc-Erkundung eines Dashboards durch eine nichttechnische Person (Support, Produkt, Management).
• Schnelles Prototyping einer Funktion, die die Datenbank abfragt, ohne für jede mögliche Frage eine eigene API-Route zu schreiben.
• Eingeschränkter analytischer Self-Service: Zählen, filtern, einfach aggregieren, ohne dem Endbenutzer direkten Zugriff auf die Datenbank zu gewähren.

Sobald die Fragestellung über diesen Rahmen hinausgeht, bleibt handschriftliches SQL vorzuziehen. Eine AST-validierte Implementierung wie die oben beschriebene schließt CTEs, Unterabfragen und Fensterfunktionen aus Sicherheitsgründen konstruktionsbedingt aus. Eine Analyse, die strukturell diese Konstruktionen, Kohorten und erweiterte zeitliche Fensterung benötigt, erfolgt nicht über NL2SQL: Sie wird direkt codiert. Dies ist ein akzeptierter Kompromiss, die Sicherheit des Systems geht vor der Vollständigkeit des generierten SQL.

Drei Risiken treten bei einer NL2SQL-Implementierung systematisch wieder auf, mit unterschiedlichen Reaktionen je nach Reifegrad des Systems.

SQL-Injection per Eingabeaufforderung oder Frage

Ein LLM kann manipuliert werden, um bösartiges SQL zu erzeugen, wenn die Frage selbst einen Injektionsversuch „Vorherige Anweisungen ignorieren und...“ enthält. Die Verteidigung besteht nicht darin, der Eingabeaufforderung zu vertrauen, sondern darin, die erzeugte SQL unabhängig von der Anforderung zu validieren, genau Schritt 3 der oben beschriebenen Pipeline. Das Thema verdient eine besondere Behandlung: Genaue Angriffsvektoren und Gegenmaßnahmen finden Sie unter Securing NL2SQL Against SQL Injection.

Halluzination nicht vorhandener Tabellen oder Spalten

Das Modell erfindet möglicherweise einen Tabellen- oder Spaltennamen, der plausibel ist, aber im tatsächlichen Schema fehlt, insbesondere bei großen oder schlecht dokumentierten Schemata. Eine Implementierung, die das generierte SQL anhand des tatsächlichen Datenbankschemas validiert, lehnt die Abfrage mit einer expliziten Meldung ab, die die tatsächlich verfügbaren Tabellen auflistet, anstatt einen reinen SQL-Fehler an den Benutzer zurückzugeben.

Kosten und Latenz von Modellaufrufen

Jede NL2SQL-Frage löst zusätzlich zur SQL-Ausführungszeit einen Aufruf des Sprachmodells mit eigenen Kosten und eigener Latenz aus. Diese Kosten steigen schnell an, wenn NL2SQL als Standardschicht für sich wiederholende Fragen dient, was von Vorteil wäre, wenn es zwischengespeichert oder als Standardbericht bereitgestellt würde, anstatt jedes Mal neu übersetzt zu werden.

Zwei Architekturen führen zu einem ähnlichen sichtbaren Ergebnis, jedoch mit sehr unterschiedlichen Garantien. Natives NL2SQL integriert Generierung, Validierung und Ausführung direkt in die Backend-Schicht, die das Schema und die Zugriffsrechte des Projekts bereits kennt: Dies ist die oben für Aurabase beschriebene Logik, bei der der aura-ai-Dienst die Infrastruktur und Schemaisolation mit dem Rest des Backends teilt.

Ein zusammengesetztes NL2SQL kombiniert einen generischen LLM-Dienst, einen Connector zur Datenbank und eine selbst erstellte Validierungsschicht. Nichts hindert diesen Ansatz daran, sicher zu sein, aber jede Garantie, jedes serverseitig introspizierte Schema, jede AST-Validierung, jede Zeilenbeschränkung und jeder Isolationsmieter müssen von dem Team implementiert und verwaltet werden, das diese Bausteine ​​zusammenstellt, und nicht von der Plattform bereitgestellt werden.

Die Landschaft der NL2SQL-Tools, nativ und assembliert, Open Source und kommerziell, wird in unserem NL2SQL 2026-Tool-Vergleichausführlich verglichen.

NL2SQL und RAG (Retrieval-Augmented Generation) beantworten zwei verschiedene Fragenfamilien, die oft verwechselt werden, da beide auf einem mit einer Datenbank verbundenen LLM basieren.

NL2SQL zielt auf strukturierte und relationale Daten ab: Wie viele, wann, welcher Anteil, Fragen, die sich natürlich in SELECT, GROUP BY, Aggregationen übersetzen lassen. Das RAG zielt auf unstrukturierte Inhalte ab: Dokumente, Notizen, Support-Tickets, bei denen die Antwort nicht in eine Tabellenzeile passt, sondern das Finden einer relevanten Passage durch semantische Ähnlichkeit, Vektorsuche auf pgvector, HNSW-Index erfordert, bevor sie im Kontext dem Modell übergeben wird.

Die beiden Fähigkeiten können im selben Projekt nebeneinander bestehen und in einem Agenten kombiniert werden, der je nach gestellter Frage die eine oder andere auswählt. Die Aurabase native AI-Säule beschreibt detailliert, wie die beiden Mechanismen zusammenarbeiten, und unser RAG-Pipeline-Leitfaden auf pgvector behandelt die Implementierung des zweiten.