SQLBot: Text-to-SQL mit RAG, Docker und einer Lizenz mit Haken

Welches Problem SQLBot löst und für wen

Die Ausgangslage ist bekannt: Fachabteilungen stellen Fragen an Daten, die in relationalen Datenbanken liegen, und zwischen Frage und Antwort steht entweder ein Datenanalyst oder ein BI-Dashboard, das für genau diese Frage nie gebaut wurde. SQLBot setzt an dieser Stelle an und übersetzt die Frage in SQL. Das README beschreibt das Ergebnis als dialogbasierte Datenanalyse, die Daten und Visualisierungen liefert und sich für weiterführende Analyse nutzen lässt.

Die Zielgruppe lässt sich aus den Integrationswegen ablesen. Das Projekt nennt Web-Einbettung, Popup-Einbettung und MCP-Aufrufe sowie die Einbettung in n8n, Dify, MaxKB und DataEase. Wer also bereits eine Plattform betreibt und dort eine Frage-Antwort-Funktion ergänzen möchte, ist der adressierte Fall. Ein DataEase-Nutzer bekommt die Funktion ohne zusätzliche Oberfläche. Ein MaxKB-Betreiber kann SQLBot als Werkzeug anbinden. Für eine einzelne Person, die eine einmalige Auswertung braucht, ist der Aufwand dagegen hoch: Docker, Postgres, ein Modell-Endpunkt und ein API-Key müssen vorhanden sein, bevor die erste Frage beantwortet wird.

RAG zwischen Schema und generiertem SQL

Das README stellt den Ablauf als Schaubild dar und benennt die Bausteine: ein großes Sprachmodell erzeugt SQL, RAG ergänzt diesen Vorgang. Der genaue Ablauf, welche Dokumente indexiert werden und wie das Retrieval gewichtet wird, geht aus dem Material nicht hervor. Belastbar ist die Beschreibung der Stellschrauben: eigene Prompts, ein Terminologiebestand und pflegbare SQL-Beispiele, die die Logik kalibrieren sollen.

Das ist der eigentliche Mechanismus hinter dem Satz, die Ergebnisse würden mit der Nutzung besser. Ein Sprachmodell kennt die Spaltennamen einer internen Datenbank nicht. Es kennt auch nicht die Konventionen eines Hauses, etwa dass ein Statusfeld als Zeichenkette mit bestimmten Kürzeln geführt wird. SQL-Beispiele und ein Terminologiebestand sind der Versuch, dieses Wissen ohne Modelltraining in den Prompt oder in den Retrieval-Kontext zu bringen. Der Preis dafür ist Pflege: Wer die Beispiele nicht aktualisiert, wenn sich das Schema ändert, bekommt SQL, das auf alte Spalten verweist.

Bemerkenswert ist, dass SQLBot mit mehreren Modell-Anbietern arbeitet. Die Tabelle nennt Alibaba Cloud Bailian, Qianfan, DeepSeek, Tencent Hunyuan, iFlytek Spark, Gemini, Kimi, Tencent Cloud, Volcano Engine und MiniMax jeweils mit OpenAI-kompatibler API. OpenAI selbst wird als nativ geführt, dazu gibt es einen Eintrag für beliebige OpenAI-kompatible Endpunkte. Für Betreiber mit Datenhaltungsauflagen ist das der relevante Punkt: Das Modell ist austauschbar, ein lokal betriebener OpenAI-kompatibler Endpunkt wäre demnach konfigurierbar. Ob das in der Praxis reibungslos funktioniert, lässt sich aus dem README nicht ableiten.

Installation in einem Befehl, Passwortwechsel danach

Das Deployment ist ein einzelner docker run. Das README gibt das Kommando vollständig an, inklusive der Ports 8000 und 8001, der Volume-Mounts für Excel-Dateien, Dateien, Bilder, Logs und die Postgres-Daten sowie des Flags --privileged=true. Der Container heißt sqlbot und wird mit --restart unless-stopped gestartet, überlebt also einen Neustart des Hosts.

Wer den Befehl übernimmt, sollte zwei Dinge beachten. Erstens liegt das Datenverzeichnis über ./data/postgresql im Arbeitsverzeichnis des Aufrufs. Ein Wechsel des Verzeichnisses bedeutet ein neues, leeres Postgres. Zweitens ist das Standardkonto im README dokumentiert: Benutzer admin, Passwort SQLBot@123456, erreichbar unter http://<Server-IP>:8000/. Ein öffentlich erreichbarer Port 8000 mit diesem Passwort ist ein offenes Tor. Die Änderung des Passworts ist der erste Schritt nach dem Start, nicht der letzte.

Für Umgebungen ohne Internetzugang verweist das README auf ein Offline-Installationspaket über das Community-Portal. Zusätzlich existiert ein Eintrag im 1Panel-App-Store. Beide Wege sind im Material nur genannt, nicht beschrieben; wer sie nutzt, sollte mit Abweichungen vom docker run rechnen. Das Flag --privileged=true ist der dritte Punkt, den man beim Härten eines Hosts nicht übersehen sollte, denn es hebt die üblichen Container-Grenzen auf.

Arbeitsbereiche, Berechtigungen und die Grenze der Isolation

SQLBot wirbt mit Ressourcentrennung auf Arbeitsbereichsebene und mit fein granulierten Datenberechtigungen. Das ist für den Einsatz in Organisationen wichtiger als die SQL-Qualität, weil ein Text-to-SQL-System jede Frage beantwortet, die die Verbindung technisch zulässt. Ohne Berechtigungskonzept wäre SQLBot ein Umgehungsweg an jeder Zeilensicherheit vorbei.

Das README nennt keine Details: nicht, wie ein Arbeitsbereich definiert wird, nicht, ob Berechtigungen auf Tabellen-, Zeilen- oder Spaltenebene greifen, und nicht, wie sich das mit den Rechten des Datenbankbenutzers in der Zieldatenbank verschneidet. Genau hier liegt die offene Frage. Wer die Datenbankverbindung mit einem Konto mit vollen Leserechten konfiguriert, hat die Anwendungsberechtigungen von SQLBot als einzige Barriere. Ein zweites Konto mit eingeschränkten Rechten in der Zieldatenbank ist die robusterere Variante, und das README widerspricht dem nicht, es erwähnt es nur nicht.

Dasselbe gilt für die Datenquelle selbst. Das README nennt nur, dass ein Datenquellen-Zugang konfiguriert wird. Welche Datenbanksysteme unterstützt werden, steht im vorliegenden Material nicht. Das ist die erste Frage, die man vor dem Deployment klären sollte, und sie lässt sich nicht aus der Startseite beantworten.

Wann SQLBot die falsche Wahl ist

Text-to-SQL hat eine strukturelle Schwäche, die kein Prompt und kein SQL-Beispiel beseitigt: Das Modell sieht das Schema, aber nicht die Absicht. Eine Frage wie die nach dem Umsatz im letzten Quartal ist mehrdeutig, wenn es mehrere Umsatzfelder, mehrere Währungen und mehrere Buchungszeitpunkte gibt. Das Modell wählt eine Interpretation. SQLBot liefert dazu die generierte Abfrage, sodass die Wahl nachvollziehbar bleibt, aber die Verantwortung für die Zahl bleibt beim Fragesteller.

Daraus folgt eine klare Grenze. Für Berichte, die eine prüfbare, versionierte Definition brauchen, ist ein modelliertes BI-Modell die bessere Grundlage. SQLBot eignet sich für Erkundung, nicht für die Zahl im Quartalsbericht. Wer aus dem System eine abrechnungsrelevante Kennzahl zieht, sollte die erzeugte Abfrage lesen, nicht nur das Diagramm.

Ein zweiter Fall spricht gegen SQLBot: eine Datenbank mit stark verschachtelten, schlecht benannten Tabellen und ohne gepflegte Kommentare. Der Aufwand, SQL-Beispiele und Terminologie so weit zu pflegen, dass brauchbare Abfragen entstehen, kann den Aufwand für ein klassisches Dashboard übersteigen. Drittens ist SQLBot kein Ersatz für Datenqualität. Wenn das Quellsystem doppelte Datensätze enthält, gibt SQLBot die doppelte Summe zurück, in einem sauberen Diagramm.

Der Unterschied zu einem BI-Werkzeug mit Assistenten

Der naheliegende Vergleich ist DataEase, das BI-Werkzeug aus demselben Haus. Der Ansatz unterscheidet sich grundlegend. DataEase arbeitet mit vorab definierten Datensätzen, Diagrammen und Filtern; die Semantik steckt im Modell, das jemand gebaut hat. SQLBot erzeugt die Abfrage zur Laufzeit aus der Frage. Das eine liefert Wiederholbarkeit, das andere Reichweite.

Ein zweiter Vergleichspunkt sind die Assistenten, die kommerzielle BI-Anbieter in ihre Oberflächen integriert haben. Deren Text-to-SQL läuft innerhalb des bereits vorhandenen semantischen Modells, kennt also die definierten Kennzahlen und Dimensionen. SQLBot arbeitet dagegen direkt gegen das Schema und muss die Semantik über Prompts, Terminologie und Beispiele nachreichen. Das ist der Grund, warum SQLBot als eigenständige Anwendung mit Einbettung positioniert ist und nicht als Funktion innerhalb eines bestehenden Modells.

Für wen das den Ausschlag gibt: Wer bereits ein gepflegtes semantisches Modell hat, verliert durch SQLBot einen Teil dieses Vorteils, weil das Modell nicht automatisch zur Grundlage der Generierung wird. Wer kein Modell hat und schnell Fragen beantworten will, gewinnt durch SQLBot überhaupt erst eine Möglichkeit.

Lizenz, Wartung und die Kosten der Anpassung

Das Repository trägt die Kennung NOASSERTION, das README benennt die FIT2CLOUD Open Source License. Nach der Beschreibung im README entspricht sie im Kern GPLv3, ergänzt um zwei Bedingungen: Logo und Copyright-Hinweise von SQLBot dürfen nicht ersetzt oder verändert werden, und abgeleitete Werke müssen die GPLv3-Pflichten einhalten. Für eine reine interne Nutzung ist das unproblematisch. Für ein Produkt, das SQLBot eingebettet ausliefert und als eigenes ausgibt, ist es das nicht. Das ist eine Einschätzung, keine Rechtsberatung; wer SQLBot in einem kommerziellen Produkt verteilt, sollte die LICENSE-Datei selbst lesen und nicht nur das README.

Zur Wartung lässt sich aus den veröffentlichten Versionen ein Muster ablesen: v1.9.0 im Juni, v1.10.0 im Juli, v1.10.1 im August, jeweils mit einem Abstand von etwa vier bis sechs Wochen. Der letzte Push liegt zeitlich nach der letzten Version. Wer SQLBot produktiv betreibt, plant also regelmäßige Upgrades ein. Der Container hält die Postgres-Daten in einem Volume, das beim Upgrade erhalten bleibt, aber ein Datenbank-Backup vor dem Wechsel ist bei einem Schema, das die Anwendung selbst migriert, kein Luxus.

Das größte versteckte Kostenstück ist nicht der Betrieb, sondern die Pflege der SQL-Beispiele und des Terminologiebestands. Diese Arbeit skaliert mit der Zahl der Datenquellen und der Änderungsrate der Schemata, nicht mit der Zahl der Nutzer. Ein Team, das diese Pflege nicht einplant, bekommt ein System, dessen Antwortqualität still nachlässt.

Redaktionelles Fazit

Wer SQLBot produktiv einsetzen will, sollte zuerst drei Dinge prüfen: ob die eigene Datenbank überhaupt als Datenquelle konfigurierbar ist, ob die FIT2CLOUD Open Source License mit dem geplanten White-Labeling vereinbar ist, und ob das Standardpasswort SQLBot@123456 vor dem ersten Start geändert wird. Für ein internes Analysewerkzeug mit eigenem Betriebsteam ist das Projekt eine naheliegende Wahl. Wer eine gehostete Lösung ohne Docker, Postgres und Modell-API-Key sucht, ist hier falsch.

Offizielle Quellen

1. dataease/SQLBot on GitHub
2. Issues
3. Project website
4. README
5. Releases