MotherDuck Dives: Mit natürlicher Sprache zu Live Dashboards

Dives sind interaktive Visualisierungen, die durch natürliche Sprache erstellt werden und direkt auf den Daten in MotherDuck aufbauen. Nutzer beschreiben, was sie sehen möchten, und ein KI-Agent generiert eine persistente, interaktive Komponente, die in ihrem Workspace neben SQL-Notebooks lebt. MotherDuck positioniert Dives als „Brücke zwischen einmaligen Fragen und stets aktuellen Dashboards". Statt ein vollständiges Dashboard zu bauen oder Visualisierungscode zu schreiben, stellen Nutzer eine Frage und speichern die Antwort als Dive, der mit den zugrunde liegenden Daten aktuell bleibt.

Was Dives besonders macht

Traditionelle Dashboards erfordern das Klicken durch Oberflächen oder das Schreiben von Visualisierungscode. Dives ersetzen das durch einfache natürliche Sprache. Sie fragen bei jedem Laden Live-Daten ab, wodurch manuelle Aktualisierungen und veraltete Snapshots entfallen. Direkt in den MotherDuck-Workspace integriert, befinden sie sich neben SQL-Notebooks und ermöglichen sofortige Exploration. Nutzer können filtern, ins Detail gehen und interagieren, ohne auf erneute Abfragen warten zu müssen. Anders als einmalig KI-generierte Diagramme sind Dives persistent, teilbar und interaktiv – keine statischen Bilder. Genau darin liegt auch der Grund, warum MotherDuck dieses neue Produkt Dives nennt und nicht einfach Dashboards, denn Dives können darüber hinausgehen, beispielsweise indem sie Daten verändern oder mit Services interagieren.

Wie Dives funktionieren

Zum Einstieg benötigt man ein MotherDuck-Konto mit mindestens einer Datenbank und einen KI-Client, der mit dem MotherDuck-MCP-Server verbunden ist. Dives sind in Business-Plänen ohne Aufpreis verfügbar. Im Hintergrund nutzen Dives MotherDucks Multi-Tenancy-Architektur für Abfragen unter einer Sekunde. Jeder Nutzer arbeitet mit dedizierter Rechenleistung, sodass es keine Verlangsamung gibt, wenn mehrere Nutzer gleichzeitig Daten erkunden. Dives sind React-Komponenten, die innerhalb der MotherDuck-UI gerendert werden, können aber derzeit noch nicht eingebettet werden, da spezifische Konfigurationen für Header und Berechtigungen erforderlich sind, um die Dives in einem iFrame auszuführen. Die Erstellung eines Dive ist im Wesentlichen ein SQL-Funktionsaufruf. Diese Aufrufe werden serverseitig auf MotherDuck ausgeführt und sind daher nicht auf rein lokalen DuckDB-Verbindungen verfügbar. Das bedeutet, dass Nutzer nicht auf einen KI-Agenten angewiesen sind, um einen Dive zu erstellen, sondern stattdessen Dives direkt per SQL erstellen, lesen, aktualisieren und löschen können. Dies könnte genutzt werden, um am Ende einer Datenpipeline eine Dive-Funktion aufzurufen und so automatisch ein Dashboard zu erstellen oder zu aktualisieren. Die Hauptanwendung von Dives ist derzeit natürlich noch ihre Erstellung durch KI-Agenten, weshalb wir uns in diesem Artikel auf diesen Anwendungsfall konzentrieren.

Zusammenarbeit und Governance

Wenn ein Dive gespeichert wird, prüft der KI-Agent, ob die abgefragten Datenbanken mit der Organisation geteilt sind. Falls nicht, schlägt er vor, sie zu teilen, damit das Team den Dive sehen kann. Nutzer können den Agenten auch explizit zum Teilen auffordern. Dabei werden organisationsweite Freigaben für alle privaten Datenbanken erstellt, die in den Abfragen des Dive referenziert werden, und der Dive wird aktualisiert, um die geteilten Referenzen zu verwenden.

Ein wichtiger Vorbehalt: Dives unterstützen derzeit keine rollenbasierte Zugriffskontrolle, und dies steht nicht auf der kurzfristigen Roadmap. Wenn ein Nutzer Zugriff auf eine Datenbank hat, kann er deren gesamten Inhalt sehen. MotherDucks Governance-Modell ist im Vergleich zu Enterprise-Lösungen vereinfacht – eine Konsequenz der Basis auf DuckDB. MotherDuck-Kunden, die kundenorientierte Anwendungen erstellen, provisionieren typischerweise eine individuelle Datenbank pro Nutzer und nutzen MotherDucks Multi-Tenancy zur Datenisolierung.

Workflow

Entscheidend ist, explizit nach einem „Dive" zu fragen. Dies signalisiert dem Agenten, die Visualisierung in MotherDuck zu persistieren, anstatt ein einmaliges Diagramm zu erzeugen. Ein Prompt wie „Erstelle einen Dive, der monatliche Umsatztrends der letzten 12 Monate zeigt" reicht aus; der Agent kümmert sich um SQL, Diagrammkonfiguration, Styling und Speicherung.

Dives erscheinen an zwei Stellen in der MotherDuck-UI: Aktuelle Dives tauchen in der linken Seitenleiste unterhalb der Notebooks auf, und eine vollständige Liste ist unter Einstellungen → Dives verfügbar. Nach der Erstellung können Nutzer einen Dive durch Folgeprompts verfeinern. Jede Aktualisierung ändert den Dive direkt und hält ihn aktuell.

Nutzer sollten spezifisch angeben, welche Visualisierung sie wünschen – einschließlich Details zu Diagrammtyp, Zeiträumen und Gruppierungen. Auch die Angabe von Tabellen- und Spaltennamen hilft: Je weniger der KI raten muss, desto besser das Ergebnis. Schließlich lohnt es sich, inkrementell zu iterieren: Mit einer einfachen Visualisierung beginnen und durch Folgeprompts schrittweise Komplexität hinzufügen.

Praxistest: Wetter und Radverkehr in München

In unserer dreiteiligen Serie Talk To Your Data haben wir MotherDucks MCP-Fähigkeiten mit Münchner Wetter- und Radzählsensordaten (2015–2025) erkundet. Für diesen Test haben wir denselben Datensatz verwendet, um zu sehen, was Dives daraus machen. Um den Kontext überschaubar zu halten, beschränkten wir unsere Prompts auf das Jahr 2025.

Ansatz 1: Der Einzelprompt

Wir starteten kühn und ignorierten bewusst die oben genannten Best Practices. Mit Claude Code, das über MCP mit MotherDuck verbunden war, setzten wir direkt auf einen einzigen umfassenden Prompt: „Erstelle einen Dive, der die Zusammenhänge zwischen täglichem Radverkehr und Wetterbedingungen im gesamten Jahr 2025 visualisiert und Kipppunkte mit den mcp_playground-Daten identifiziert."

Im Vergleich zum „normalen" Claude erstellt Claude Code eine lokale Vorschau, bevor der Dive hochgeladen wird. Erst auf die explizite Aufforderung zum Speichern erschien der Dive in MotherDuck. Zusätzlich fühlt sich das Wechseln zwischen Terminal und Browser recht unintuitiv an, insbesondere da der MotherDuck-Workspace bereits SQL- und klickbasierte Interaktion unterstützt. Wir sind mit dieser Beobachtung nicht allein. Im offiziellen MotherDuck-Slack-Channel bemerkte MotherDucks Garrett O'Brien: „Noch nichts Offizielles zu berichten, aber ich habe in der letzten Stunde drei separate Anfragen dazu erhalten, es ist also sehr präsent." MotherDucks Begründung für den aktuellen Ansatz ist, dass sie Daten in den bestehenden Arbeitsumgebungen der Nutzer (ChatGPT, Claude usw.) bereitstellen möchten, anstatt sie auf eine separate UI umzuleiten.

Nach etwa zwei Minuten – wovon die meiste Zeit für die lokale Vorschau aufgewendet wurde – erschien der Dive in unserem Workspace. Die erste Visualisierung ist ein Streudiagramm von Tagestemperatur vs. Gesamtzahl der Radfahrten, aufgeteilt in trockene (blau) und Regen-/Schneetage (rot). Regentage zeigen bei gleicher Temperatur durchgehend niedrigere Radfahrerzahlen, mit detaillierten Tooltips an jedem Punkt.

Der Kipppunkt-Tab enthält ein Balkendiagramm, das Tage in 2°C-Temperaturbänder gruppiert. Die stärkste Beschleunigung der Radfahrerzahlen tritt im Bereich 0–15°C auf, wo sich der Verkehr ungefähr verdoppelt. Eine Referenzlinie markiert den größten einzelnen Sprung.

Die letzte Grafik ist eine Monatsübersicht – ein Zwei-Achsen-Liniendiagramm, das die durchschnittlichen täglichen Fahrten und die Durchschnittstemperatur im Jahresverlauf eng korreliert zeigt.

Ansatz 2: Iterative Verfeinerung

Beim zweiten Durchlauf wählten wir den entgegengesetzten Ansatz und fragten zunächst nach einem „ersten allgemeinen Dive über die Daten" für 2025:

Dann baten wir Claude, sich auf Wetterbedingungen und Radverkehr zu konzentrieren. Der verfeinerte Dive zeigte bereits ein differenzierteres Bild: Das Streudiagramm unterschied nun zwischen trocken, Regen, Schneeregen und Schnee – im Vergleich zur gröberen Kategorisierung trocken vs. Regen/Schnee aus Ansatz 1.

Bemerkenswert ist, dass die Gesamtverteilungen in beiden Streudiagrammen identisch sind. Der iterative Ansatz veränderte nicht die Datenmenge, sondern verbesserte deren Granularität. In unserer früheren Serie Talk To Your Data beobachteten wir einen ähnlichen Effekt beim Vergleich kommentierter und unkommentierter Datenbanken. Hier wurde in beiden Durchläufen dieselbe kommentierte Datenbank verwendet. Der Unterschied war, dass der Agent durch seine eigene vorangegangene Exploration reichhaltigeren Kontext aufbaute. Dies erzeugte auch zwei zusätzliche Diagramme: durchschnittliche Fahrten nach Temperaturband und durchschnittliche Fahrten nach Niederschlagsniveau.

Schließlich gaben wir Claude einen Prompt ähnlich der Einzelprompt-Version aus Ansatz 1. Der MotherDuck-Workspace aktualisiert sich automatisch, wenn der Agent neuen Code hochlädt.

Die finale Iteration ist deutlich ausgereifter als das Einzelprompt-Ergebnis. Der Agent liefert Kipppunktanalysen über Temperatur, Sonnenschein und Niederschlag hinweg. Der Temperatur-Kipppunkt bleibt bei der 18°C-Marke mit identischen Radfahrerzahlen, was die Konsistenz über beide Ansätze bestätigt.

Weitere Möglichkeiten

Mit einem soliden Dashboard ausgestattet, erkundeten wir zusätzliche Fähigkeiten. Wir fügten interaktive Filter und Steuerelemente hinzu, die Nutzer an ihre Bedürfnisse anpassen können. Der Agent versuchte auch, eine Tägliche Datentabelle einzufügen, die zunächst einen Runtime Error auslöste. Nachdem wir darauf hinwiesen, behob der Agent das Problem und lieferte eine funktionierende Tabelle mit täglichen Fahrten, Durchschnittstemperatur, Sonnenstunden, Regen und Windgeschwindigkeit.

Dann fragten wir, wie sich Wetterfaktoren kombinieren – ob zum Beispiel Sonnenschein bei Wärme wichtiger wird – indem wir ein Mehrfaktormodell anforderten, das den Radverkehr über Wetterkombinationen hinweg zeigt, um optimale Radfahrbedingungen zu identifizieren:

Und zum Spaß baten wir den Agenten, den originalen Dive im Windows-95-Stil umzugestalten:

Fazit

Dives stellen einen bedeutsamen Fortschritt dar, Datenvisualisierung zugänglicher zu machen. Durch die Verbindung natürlichsprachiger Prompts mit persistenten, live-aktualisierten Dashboards beseitigen sie einen Großteil der Reibung, die traditionell mit Datenexploration verbunden ist – ohne SQL-Expertise oder Visualisierungsframeworks.

Unsere Tests haben eine zentrale Erkenntnis ergeben: Iteration liefert bessere Ergebnisse als Einzelprompts. Beide Ansätze identifizierten dieselben zugrunde liegenden Muster (den 18°C-Kipppunkt, die Regen-Radverkehr-Korrelation), aber der iterative Weg ergab differenziertere Kategorisierungen und zusätzliche Analysen. Der Agent baut besseren Kontext auf, wenn er die Daten inkrementell erkundet. Dives funktionieren am besten als Gespräch, nicht als Befehl.

Die Bonusexperimente zeigten echte Flexibilität – interaktive Filter, Mehrfaktormodelle, Fehlerbehebung durch Konversation und sogar kosmetische Neugestaltung funktionierten allesamt über natürliche Sprache. Dives sind keine statischen Berichte, sondern interaktive Anwendungen, die sich mit den Bedürfnissen der Nutzer weiterentwickeln.

Zwei Reibungspunkte bleiben. Erstens erfordert der Workflow derzeit das Wechseln zwischen Terminal/KI-Client und Browser, was im Widerspruch zu MotherDucks ansonsten integriertem Workspace steht. Zweitens bedeutet das Fehlen rollenbasierter Zugriffskontrolle, dass Dives nicht für jeden Enterprise-Anwendungsfall geeignet sind. Teams mit strengen Datenzugriffsanforderungen müssen um diese Einschränkung herum architektonisch planen und Datenbanken pro Nutzer verwenden.

Für Teams mit MotherDuck-Business-Plänen ist das Wertversprechen klar: Mit einfachen Fragen beginnen, durch Konversation iterieren und zu anspruchsvollen, stets aktuellen Visualisierungen gelangen, die neben den eigenen Daten leben. Die Tatsache, dass die Dive-Erstellung ein SQL-Funktionsaufruf ist, eröffnet eine besonders spannende Möglichkeit – Datenpipelines, die automatisch Dashboards aus ihren Ergebnissen erzeugen und so die Grenze zwischen Datenverarbeitung und Datenpräsentation verwischen.