WrenAI: Text-to-SQL mit einer Kontextschicht, die im Git liegt

Das Problem liegt neben der Datenbank, nicht in ihr

Ein Sprachmodell kann aus einem Schema SQL ableiten. Es weiß dann, dass es eine Spalte namens status gibt, aber nicht, dass der Wert 3 storniert bedeutet und dass Umsatz in dieser Firma ohne Steuern gerechnet wird. Genau diese Lücke adressiert WrenAI nach eigener Darstellung: Die Geschäftslogik, also Definitionen, Enums, Einheiten und freigegebene Joins, liegt außerhalb der Datenbank, und Agenten raten daran vorbei. Das Repository beschreibt das Ziel als governed text-to-SQL über eine offene Kontextschicht, die Business-Semantik, freigegebene Definitionen, Beispiele, Erinnerung und Governance zusammenführt, ergänzt um unstrukturiertes Wissen aus Dokumenten, Wikis und Chat-Threads. Die Zielgruppe sind demnach Agenten-Bauer und Datenplattform-Teams, die nicht nur plausibles SQL wollen, sondern nachvollziehbare Ergebnisse. Wer lediglich ein einzelnes Diagramm aus einer CSV-Datei braucht, gehört ausdrücklich nicht dazu, das sagt die README selbst.

MDL, Dry-Plan-Validierung und ein Dashboard im Browser

Die Architektur ruht auf zwei Schichten. Unten liegt das semantische Modell, in der Dokumentation MDL genannt, das als versionierbare Datei mit Belegen vorliegt. Darüber sitzt die Kontextschicht, die zusätzlich eine Datei instructions.md mit Unternehmensdefinitionen und eine Erinnerung daran speichert, welche Abfragen funktioniert haben. Der Ablauf laut README: Der Agent übersetzt eine Frage in SQL, wobei Schema-Retrieval, MDL-Planung, Dry-Plan-Validierung und strukturierte Fehler greifen sollen. Die Validierung prüft die Abfrage also, bevor sie ausgeführt wird. Ausgeführt wird sie über Konnektoren zu über 22 Datenquellen, darunter BigQuery, Snowflake, PostgreSQL, ClickHouse, Amazon Redshift und Databricks. Anschließend lässt sich jede Antwort in ein teilbares Dashboard verwandeln, das browser-seitig über wren-core-wasm läuft und sich laut README mit einem Befehl auf ein eigenes Vercel- oder Cloudflare-Pages-Konto ausliefern lässt. Bemerkenswert ist, dass die Engine selbst keine Oberfläche voraussetzt: Der Agent orchestriert, die Spur bleibt in seiner Argumentation.

Installation über CLI und Discovery-Stub

Der Einstieg ist bewusst agentengetrieben. Zuerst die CLI, wobei DuckDB bereits im Kern enthalten ist:

pip install wrenai pip install "wrenai[postgres,memory]"

Die Extras werden also pro Datenquelle und für die Erinnerungsfunktion nachinstalliert. Danach folgt laut README ein einteiliger Discovery-Stub für den jeweiligen KI-Client, der dem Agenten mitteilt, welche Werkzeuge verfügbar sind. Die Workflow-Anleitungen liegen nicht als statische Dokumentation vor, sondern werden von der CLI auf Anfrage ausgeliefert, damit der Inhalt zur installierten Version passt. Für Nutzer in Festlandchina enthält die README einen Hinweis zu langsamen oder fehlschlagenden pip-Installationen, der im vorliegenden Material allerdings abgeschnitten ist. Das Repository gliedert sich seit Mai 2026 neu: Die frühere Wren Engine ist unter core/ in dieses Repository eingezogen, das alte Docker-basierte Chat-Produkt liegt auf dem Branch legacy/v1 unter dem Tag v1-final und heißt jetzt Wren GenBI Classic.

Governance endet an der Zeilenberechtigung

Die README ist an dieser Stelle ungewöhnlich deutlich. Zeilen- und Spaltenberechtigungen sowie Zugriffskontrolle sind nicht im offenen Kern enthalten, sondern dem Cloud- bzw. Self-hosted-Angebot vorbehalten. Wer WrenAI in einer Umgebung einsetzt, in der verschiedene Nutzer unterschiedliche Daten sehen dürfen, bekommt aus dem Open-Source-Teil also keine vollständige Absicherung. Weitere Einschränkungen ergeben sich aus dem Zuschnitt: Die Qualität hängt direkt an der Pflege des MDL und der instructions.md. Ein veralteter Join oder eine fehlende Enum-Definition führt zu Abfragen, die formal korrekt sind und fachlich falsch. Die Dry-Plan-Validierung fängt Syntax- und Planungsfehler, nicht aber eine falsch modellierte Kennzahl. Das Repository nennt außerdem einen Eval-Runner als Bestandteil der Korrektheits-Primitive, ohne im vorliegenden Ausschnitt zu erläutern, wie die Testfälle gepflegt werden. Wer keine Person hat, die das semantische Modell regelmäßig reviewt, verliert den Vorteil gegenüber einem ungeführten Agenten.

Wo WrenAI mehr leistet als ein reines semantisches Modell

Die naheliegende Alternative ist eine schlanke semantische Schicht, etwa dbt-Metriken oder ein Cube-Modell. Der Unterschied liegt im Umfang der Kontextschicht. Ein reines semantisches Modell liefert Definitionen auf Schemaebene. WrenAI beansprucht zusätzlich Nicht-Schema-Wissen: Beispiele, Erinnerung an funktionierende Abfragen und Dokumente außerhalb der Datenbank. Ein weiterer Unterschied ist die Ausführung. Eine semantische Schicht beantwortet Abfragen innerhalb ihres eigenen Definitionsbereichs. WrenAI erzeugt SQL über 22+ Quellen und liefert zusätzlich ein deploybares Dashboard, was eine semantische Schicht nicht tut. Umgekehrt formuliert die README selbst die Grenze: Ein reines semantisches Modell deckt Definitionen ab, WrenAI deckt Definitionen plus Nicht-Schema-Wissen plus Ausführung ab. Wer bereits eine gepflegte semantische Schicht betreibt und nur die Abfragegenerierung verbessern will, muss abwägen, ob der zusätzliche Kontextpflegeaufwand sich rechnet.

Lizenzlage und Release-Takt

Die README zeigt ein Apache-2.0-Badge und verweist auf die LICENSE-Datei im Repository. Die Metadaten des Repositorys melden dagegen NOASSERTION, also eine nicht automatisch zuordenbare Lizenz. Diese Diskrepanz sollte man vor einem produktiven Einsatz anhand der LICENSE-Datei selbst klären, zumal das Projekt einen offenen Kern mit einem kostenpflichtigen Cloud- und Self-hosted-Angebot kombiniert. Zu den Betriebskosten lässt sich aus dem Material nur der Release-Takt ablesen: Zwischen wren-v0.13.4 am 2. September 2026 und wren-v0.14.0 am 8. September 2026 liegen sechs Tage, dazu ein separates Paket wren-pydantic in Version 0.3.0. Ein solcher Rhythmus bedeutet regelmäßige Upgrades. Da die Workflow-Anleitungen von der CLI ausgeliefert werden und damit an die installierte Version gebunden sind, ist die Upgrade-Last zumindest teilweise abgefedert. Ob Breaking Changes zwischen Minor-Versionen auftreten, geht aus dem vorliegenden Ausschnitt nicht hervor.

Redaktionelles Fazit

WrenAI passt zu Teams, deren Fachlogik außerhalb der Datenbank liegt und die diese Definitionen prüfbar in Git halten wollen. Wer nur eine einzelne CSV-Datei visualisieren möchte, ist mit einem klassischen BI-Werkzeug schneller. Vor dem Einsatz sollte man prüfen, ob die eigene Datenquelle in der Liste der 22+ Quellen enthalten ist, ob die Lizenzdatei des Repositorys tatsächlich Apache-2.0 ausweist (GitHub meldet NOASSERTION) und ob Zeilen- und Spaltenberechtigungen benötigt werden, denn diese Funktion ist dem Cloud- bzw. Self-hosted-Angebot vorbehalten.

Offizielle Quellen

1. Canner/WrenAI on GitHub
2. Issues
3. Project website
4. README
5. Releases