Chat2DB: Lokaler Datenbank-Client mit eigenem AI-Modell

Welches Problem Chat2DB adressiert

Viele Teams arbeiten nicht mit einer Datenbank, sondern mit einem Dutzend. MySQL für die Anwendung, PostgreSQL für Analytics, ClickHouse für Zeitreihen, Redis für Caches, dazu ein älteres Oracle oder SQL Server. Jede dieser Verbindungen braucht heute ein eigenes Werkzeug oder ein eigenes Plugin, und die Abfragen wandern zwischen diesen Oberflächen hin und her. Chat2DB setzt an dieser Stelle an: ein Client, der laut README über 40 Datenbanken abdeckt, darunter MySQL, PostgreSQL, Oracle, SQL Server, ClickHouse, MongoDB, Redis, SQLite, MariaDB, TiDB, Hive, DB2, Snowflake, BigQuery, Elasticsearch, Trino, TimescaleDB, Greenplum, YugabyteDB, CrateDB, QuestDB, Apache IoTDB, Firebird, HSQLDB und Apache Derby. Die Zielgruppe benennt das README selbst: Entwickler, DBAs, Analysten und Datenteams. Der zweite Teil des Versprechens ist der AI-Assistent, der SQL in natürlicher Sprache erzeugen, erklären und optimieren soll. Anders als bei vielen vergleichbaren Produkten bringt man sein eigenes Modell mit, statt an einen Anbieter gebunden zu sein.

Ein Prozess, vier Oberflächen

Chat2DB ist in Java geschrieben und läuft als ein Dienst, der über verschiedene Wege erreichbar ist. Das README nennt Desktop-Anwendung, Web, Docker und eine separate CLI, die unter OtterMind/Chat2DB-CLI liegt und MCP-Unterstützung mitbringt. Die Desktop-Variante ist die einzige, die einen fehlenden Verschlüsselungsschlüssel selbst erzeugt. Web- und Headless-Start schlagen dagegen fehl, wenn kein gültiger Schlüssel vorliegt. Diese Asymmetrie ist kein Detail, sondern bestimmt, wie man das Produkt ausrollt: Wer den Serverbetrieb plant, muss den Schlüssel vorher erzeugen, nicht danach. Die Datenbankanbindung läuft über JDBC. Neue JDBC-Datenbanken lassen sich laut README allein durch Konfiguration ergänzen, ohne Codeänderungen. Das ist der architektonisch interessanteste Punkt, weil es die Zahl 40+ zu einer Momentaufnahme macht und nicht zu einer Obergrenze. Wer eine Nischendatenbank mit JDBC-Treiber hat, kann sie selbst nachtragen. Eigene JDBC-Treiber sind allerdings ausführbarer Java-Code, und die Sicherheitshinweise sagen ausdrücklich, man solle sie nur aus vertrauenswürdigen Quellen installieren.

Start per Docker: Schlüssel zuerst

Der dokumentierte Weg für den Serverbetrieb beginnt mit einem Klon des Repositories, weil das Initialisierungsskript darin liegt. Danach folgen zwei Schritte in fester Reihenfolge. Zuerst:

./script/security/init-community-encryption-key.sh

dann der Container:

docker run --detach \ --name chat2db-community \ --restart unless-stopped \ --publish 127.0.0.1:10825:10825 \ --volume "$HOME/.chat2db-community-docker:/root/.chat2db-community" \ --env CHAT2DB_COMMUNITY_ENCRYPTION_KEY_FILE=/run/secrets/chat2db-community-encryption.key \ --volume "$HOME/.config/chat2db-community/encryption.key:/run/secrets/chat2db-community-encryption.key:ro" \ chat2db/chat2db:latest

Die Oberfläche ist danach unter http://localhost:10825 erreichbar. Die Portbindung auf 127.0.0.1 ist bewusst gewählt und deckt sich mit den Sicherheitshinweisen, die verlangen, den HTTP-Dienst nicht anderen Nutzern oder unvertrauenswürdigen Netzen auszusetzen. Alternativ gibt es eine Compose-Datei unter docker/docker-compose.yml. Ein Punkt, der beim Aktualisieren stolpert: Die docker-run-Variante legt Anwendungsdaten in $HOME/.chat2db-community-docker ab, die Compose-Variante nutzt das benannte Volume chat2db-community-data. Diese beiden Orte teilen keine Daten. Wer zwischen den Varianten wechselt, sieht eine leere Installation und hält sie womöglich für einen Fehler. Zusätzlich verwendet Version 5.3.0 das Verzeichnis /root/.chat2db-community und migriert laut README nicht automatisch aus älteren Images, die /root/.chat2db benutzt haben. Ein Upgrade von einer älteren Version ist damit ein manueller Umzug, kein Selbstläufer.

Der Verschlüsselungsschlüssel ist der kritische Teil

Chat2DB verschlüsselt gespeicherte Datasource-Passwörter und AI-API-Schlüssel mit AES-256-GCM unter einem Schlüssel pro Installation. Das Skript legt ihn unter ~/.config/chat2db-community/encryption.key ab. Er muss gültiges Base64 sein, das exakt 32 Byte dekodiert, im erzeugten Standardformat also 44 Zeichen mit abschließendem Gleichheitszeichen. Das ist Schlüsselmaterial, kein Passwort, das man sich merkt. Die Konsequenz ist unangenehm und im README deutlich benannt: Wird die Datei ersetzt oder geht sie verloren, sind zuvor gespeicherte Datasource-Passwörter und API-Schlüssel unlesbar. Sie muss separat gesichert und über Upgrades und Container-Rebuilds hinweg mitgeführt werden. Ein Detail, das für den Datenschutz spricht: Datasource-Passwörter und AI-API-Schlüssel nutzen denselben Schlüssel, aber getrennte authentifizierte AAD-Werte. Ciphertext des einen Zwecks lässt sich damit nicht als der andere entschlüsseln. Für einen Einzelplatz-Client ist das eine saubere Trennung. Für einen geteilten Server wäre sie zu wenig, doch dazu unten mehr.

Lizenz und Wartung: zwei offene Punkte

Die Metadaten weisen als Lizenz NOASSERTION aus. Das ist keine Lizenz, sondern die Abwesenheit einer maschinenlesbaren Angabe. Wer Chat2DB gewerblich einsetzen will, muss die LICENSE-Datei im Repository selbst lesen und im Zweifel juristischen Rat einholen. Aus der Beschreibung allein lässt sich nicht ableiten, ob und unter welchen Bedingungen eine kommerzielle Nutzung erlaubt ist. Das ist bei einem Client, der Zugangsdaten zu Produktionsdatenbanken hält, kein Nebenaspekt. Die Release-Kadenz ist dagegen gut dokumentiert: v5.3.3 am 6. August 2026, v5.3.4 am 20. August, v5.3.5 am 2. September. Das sind drei Releases in rund vier Wochen. Für Nutzer bedeutet das schnelle Fehlerbehebungen, aber auch, dass die Upgrade-Schritte aus dem README relevant bleiben. Wer einen Container rebuildet, muss den Schlüssel unter ~/.config/chat2db-community/encryption.key bewahren und die Datenverzeichnisse im Blick behalten. Der Aufwand liegt also nicht in der Installation, sondern in der Disziplin danach.

Wo Chat2DB das falsche Werkzeug ist

Die Sicherheitshinweise sind ungewöhnlich klar: Chat2DB Community ist eine Single-User-Anwendung ohne Benutzerkonten und ohne Autorisierungsgrenzen zwischen Nutzern. Der Dienst gehört an 127.0.0.1 oder ::1, nicht in ein geteiltes Netz. Damit fällt die naheliegende Idee weg, den Web-Modus als internes Team-Portal zu betreiben, in dem mehrere Personen dieselben Datenquellen nutzen. Es gibt keine Rollen, keine Zugriffstrennung, keine Audit-Spur pro Person. Wer so etwas braucht, muss auf ein Mehrbenutzer-Produkt ausweichen. Ein zweiter Grenzfall: Der AI-Assistent arbeitet mit einem selbst gewählten Modell, und das README zählt AI-Antworten ausdrücklich zu den unvertrauenswürdigen Daten, ebenso wie importierte Konfigurationsdateien, Archive, SQL-Dateien und Datenbankinhalte. Wer generierte SQL-Anweisungen ungeprüft gegen eine Produktionsdatenbank laufen lässt, handelt gegen die eigene Trust-Boundary-Dokumentation. Und wer keine JDBC-Datenbank hat, für die es einen Treiber gibt, für den nützt die Plugin-Konfiguration nichts.

Alternative: DBeaver

Der offensichtliche Vergleich ist DBeaver, ein ebenfalls Java-basierter, quelloffener Datenbank-Client mit JDBC-Treibern für eine sehr breite Datenbankliste. Der Unterschied liegt nicht in der Abdeckung, sondern im Ansatz. DBeaver ist primär ein klassischer Client: SQL-Editor, Metadatenbrowser, Datenexport, ER-Diagramme, ohne AI-Schicht im Kern. Chat2DB integriert den AI-Assistenten als Teil des Arbeitsbereichs und richtet sich damit an Nutzer, die Abfragen in natürlicher Sprache formulieren, erklären oder umschreiben lassen wollen, mit einem selbst gewählten Modell. Wer diese Funktion nicht braucht, für den ist die zusätzliche Angriffsfläche eines Modell-Endpunkts samt gespeichertem API-Schlüssel ein Argument gegen Chat2DB. Wer sie braucht, für den ist der BYO-Ansatz der eigentliche Grund, sich das Projekt anzusehen. Ein zweiter Unterschied ist der MCP-fähige CLI, der in einem separaten Repository liegt und den Client auch für skriptgesteuerte Abläufe öffnet.

Für wen sich der Aufwand lohnt

Chat2DB ist für den Einzelplatz gebaut, und dort funktioniert das Modell aus einem Dienst, mehreren Oberflächen und einem selbst verwalteten Schlüssel kohärent. Wer täglich zwischen MySQL, PostgreSQL, ClickHouse und Redis springt und dabei ein eigenes Modell anbinden will, findet hier einen Arbeitsplatz statt vier. Wer dagegen einen geteilten Dienst für ein Team sucht, sollte nicht mit der Portbindung experimentieren, sondern ein anderes Produkt wählen, weil die fehlende Nutzertrennung nicht konfigurierbar ist. Konkret zu prüfen sind drei Dinge, bevor man Zeit investiert: der Inhalt der LICENSE-Datei, die Migrationshinweise für den Wechsel von älteren Images auf /root/.chat2db-community, und ob das eigene Modell über den vorgesehenen Weg angebunden werden kann. Erst danach lohnt der Blick auf die Plugin-Konfiguration für eigene JDBC-Treiber.

Redaktionelles Fazit

Chat2DB passt zu einzelnen Entwicklern, DBAs und Analysten, die viele verschiedene Datenbanken von einem lokalen Arbeitsplatz aus bedienen und dabei ein eigenes AI-Modell anbinden wollen. Wer den Dienst mehreren Personen zugänglich machen oder als geteiltes Team-Werkzeug betreiben will, ist hier falsch: laut Sicherheitshinweisen gibt es keine Benutzerkonten und keine Autorisierungsgrenzen zwischen Nutzern. Vor dem ersten Start sollte man die Datei ~/.config/chat2db-community/encryption.key erzeugen und separat sichern, weil ohne sie gespeicherte Datasource-Passwörter und API-Schlüssel unlesbar bleiben. Und vor jedem produktiven Einsatz ist zu klären, was die LICENSE-Datei tatsächlich erlaubt, denn die Metadaten nennen nur NOASSERTION.

Offizielle Quellen

1. Issues
2. OtterMind/Chat2DB on GitHub
3. Project website
4. README
5. Releases