DB-GPT: Agentenplattform für Datenanalyse mit SQL, Code und Skills

Welche Lücke DB-GPT schließt und für wen

Ein Sprachmodell kann eine Frage zu Umsatzzahlen nicht beantworten, wenn es die Tabelle nicht sieht. Der übliche Weg dorthin führt über handgeschriebene SQL-Abfragen, Exporte und ein separates Skript für die Auswertung. DB-GPT setzt genau an dieser Kette an: Das Projekt beschreibt sich selbst als agentischer KI-Datenassistent, der sich mit Datenbanken, CSV- und Excel-Dateien, Warehouses und Wissensbasen verbindet, SQL und Code schreibt und die Ausführung in einer Sandbox vornimmt. Die Zielgruppe ist damit enger, als der Begriff Assistent vermuten lässt. Angesprochen sind Teams, die wiederkehrende Auswertungen automatisieren wollen, etwa Profiling-Berichte über eine Datenbank oder Finanzberichtsanalysen mit Charts und erzählendem Text. Wer nur einmalig eine Abfrage braucht, ist nicht die Zielgruppe. Interessant wird das Projekt dort, wo Analysewege wiederholbar sind und als Skill abgelegt werden können.

Agent, AWEL, RAG, Skills: die sichtbare Architektur

Das README nennt vier Bausteine, auf denen Anwendungen aufsetzen: Agents, AWEL, RAG und Multi-Model-Unterstützung. AWEL wird nicht weiter erklärt, es erscheint nur als Name neben den anderen. Wer wissen will, was AWEL genau tut, muss die Dokumentation unter docs.dbgpt.cn aufrufen; aus dem Repository-Ausschnitt lässt sich das nicht ableiten. Klarer ist der Datenfluss auf der Anwendungsebene: Eine Aufgabe wird in Schritte zerlegt, der Agent ruft Werkzeuge auf, generiert SQL für strukturierte Quellen und Python für alles, was Berechnung oder Bereinigung erfordert. Die Ausführung läuft in einer isolierten Umgebung, die das README als Sandbox bezeichnet. Ergebnisse fließen in Charts, Dashboards, HTML-Berichte und Zusammenfassungen. Neu hinzugekommen ist die Ebene der Skills: domänenspezifisches Wissen und Ausführungsabläufe werden als wiederverwendbare Einheit verpackt und geladen. Das ist die eigentliche Erweiterungsstelle. Ein Team, das seine Kennzahlenlogik nicht in Prompts duplizieren will, legt sie als Skill ab.

Installation über das Shell-Skript und die Profile

Der dokumentierte Einstieg ist ein Einzeiler für macOS und Linux: curl -fsSL https://raw.githubusercontent.com/eosphoros-ai/DB-GPT/main/scripts/install/install.sh | bash. Wer den Anbieter gleich mitgeben will, setzt eine Umgebungsvariable vor das Skript und übergibt ein Profil. Für OpenAI sieht das so aus: curl -fsSL ... | OPENAI_API_KEY=sk-xxx bash -s -- --profile openai. Für Kimi 2.5 über die Moonshot-API lautet die Variable MOONSHOT_API_KEY, für MiniMax MINIMAX_API_KEY, jeweils mit dem passenden Profilnamen. Bemerkenswert ist der Hinweis am Ende des Ausschnitts: Wer bereits einen lokalen Checkout hat, kann ihn wiederverwenden, statt das Skript nach ~/.dbgpt/DB-GPT klonen zu lassen. Das ist relevant für alle, die eine eigene Verzeichnisstruktur oder ein bestehendes Deployment pflegen. Die Profile kapseln die Modellkonfiguration, sodass ein Wechsel des Anbieters nicht durch die gesamte Konfiguration führt. Ob das Skript auch unter Windows trägt, sagt der Ausschnitt nicht; dort ist mit manueller Einrichtung zu rechnen. Eine Docker-Variante wird im vorliegenden Material nicht gezeigt.

Die Sandbox ist die interessanteste und die unklarste Zusage

Dass ein Agent Python schreibt und ausführt, ist der Punkt, an dem aus einem Analysewerkzeug ein Betriebsrisiko wird. DB-GPT adressiert das explizit mit isolierten Umgebungen und führt die Sandbox als eigenes Verkaufsargument. Das README bleibt allerdings bei der Zusage stehen. Es nennt weder die Isolationsgrenze noch die verfügbaren Ressourcenlimits, noch ob Netzwerkzugriff innerhalb der Sandbox möglich ist. Genau diese drei Angaben entscheiden aber darüber, ob der Ansatz in einer Umgebung mit sensiblen Daten tragfähig ist. Wer DB-GPT evaluiert, sollte die Sandbox deshalb nicht als erledigt betrachten, sondern als ersten Prüfpunkt: Welche Laufzeit wird verwendet, welche Bibliotheken sind vorinstalliert, und was passiert bei einem Skript, das den Speicher volllaufen lässt. Das ist keine Kritik an der Idee, sondern an der Dokumentationstiefe an der riskantesten Stelle des Systems.

Wann DB-GPT das falsche Werkzeug ist

Nicht jede Datenfrage braucht einen Agenten. Wenn die Abfrage feststeht und sich nicht ändert, ist eine materialisierte View oder ein geplanter Job billiger, schneller und deterministischer als ein Modellaufruf. Der zweite Fall betrifft die Genauigkeit: Ein Agent, der SQL generiert, kann eine Abfrage liefern, die syntaktisch korrekt ist und die falsche Frage beantwortet. Bei aggregierten Kennzahlen fällt das nicht immer sofort auf. Wo Fehler nicht sichtbar werden dürfen, etwa in der Berichterstattung nach außen, gehört eine Prüfinstanz zwischen Generierung und Ausführung. Der dritte Fall ist der Betrieb: DB-GPT ist ein Dienst mit Modellanbindung, Datenquellen und Ausführungsumgebung. Wer keine Person hat, die Updates, Modellwechsel und Abhängigkeitskonflikte pflegt, sollte die Komplexität nicht unterschätzen. Die Versionshistorie mit v0.8.0, v0.8.1 und v0.8.2 innerhalb von rund fünf Monaten zeigt ein aktives, aber auch schnell wanderndes Projekt.

Alternative: Text-to-SQL als Bibliothek statt als Plattform

Der naheliegende andere Weg ist, die SQL-Generierung als Baustein in die eigene Anwendung zu holen, statt eine komplette Assistenten-Plattform zu betreiben. Vanna.ai ist ein solcher Vertreter: Es trainiert auf Schema- und Frage-Antwort-Paaren und gibt SQL zurück, die die Anwendung selbst ausführt. Der Unterschied liegt nicht in der Modellqualität, sondern in der Verantwortung. Vanna übernimmt weder Ausführung noch Sandbox noch Berichtserzeugung; das bleibt beim Aufrufer. DB-GPT nimmt dem Team diese Teile ab, verlangt dafür aber, den Betrieb des Dienstes zu übernehmen und sich an die Struktur aus Agents, Skills und Datenquellen zu halten. Für ein einzelnes internes Dashboard ist die Bibliotheksvariante meist die günstigere Wahl. Sobald mehrere Auswertungen, Dateien und Wissensbasen zusammenkommen und Ergebnisse als Bericht zurückfließen sollen, verschiebt sich das Bild zugunsten der Plattform.

Pflegeaufwand, Lizenz und was vor dem Einsatz zu klären ist

DB-GPT steht unter der MIT-Lizenz. Das ist permissiv: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Für die meisten internen Einsätze entstehen daraus keine Pflichten zur Offenlegung eigenen Codes. Rechtlich verbindlich ist das nicht, das ist eine Einordnung und keine Beratung. Der Pflegeaufwand liegt woanders: bei den Modellendpunkten, den Datenquellen-Treibern und den Python-Abhängigkeiten der Analyseumgebung. Die drei Releases innerhalb weniger Monate deuten auf eine gewisse Umbauintensität hin, was bei einem Projekt dieser Breite zu erwarten ist. Vor dem Einsatz sollte man drei Dinge konkret prüfen: ob die eigene Datenquelle in der Liste der unterstützten Quellen steht, wie die Sandbox konfiguriert wird und welche Rechte sie hat, und ob die Modellanbindung über ein Profil des Installers abgedeckt ist oder manuell nachgezogen werden muss. Wer diese drei Punkte beantworten kann, kann den Rest des Stacks realistisch einschätzen.

Redaktionelles Fazit

Wer eine selbst gehostete Agentenschicht braucht, die SQL generiert, Python ausführt und die Ergebnisse als Bericht zurückgibt, findet in DB-GPT ein MIT-lizenziertes Fundament mit klarer Trennung von Agent, Workflow und Datenquelle. Wer dagegen nur gelegentlich eine Frage an eine Postgres-Instanz stellt, sollte zuerst das Sandbox-Modell und die Profilauswahl im Installer prüfen, bevor er den Betriebsaufwand für einen eigenen Dienst auf sich nimmt.

Offizielle Quellen

1. eosphoros-ai/DB-GPT on GitHub
2. License: MIT
3. Project website
4. README
5. Releases