DuckDB 2.0 zeigt, warum Analysen näher an den Daten bleiben sollten

Die Cloud hat uns jahrelang davon überzeugt, dass ernsthafte Analysen in irgendeinem fremden Rechenzentrum stattfinden müssen. DuckDB 2.0 kommt mit einem interessanteren Vorschlag: Vielleicht ist die intelligenteste Architektur nicht Cloud gegen lokal, sondern die bewusste Entscheidung, welche Arbeit die eigene Maschine niemals verlassen sollte.

DuckDB 2.0.0 LTS, Codename „Cinnamon Teal“, ist am 21. Oktober 2026 erschienen. Die Version ist bislang das umfangreichste Feature-Release des Projekts und trägt den Codenamen „Cinnamon Teal“. Enthalten sind ein ausgereiftes Quack-Protokoll, asynchrone Ein-/Ausgabe, ein erstklassiger VARIANT-Typ, ein Agentenmodus, Trigger und ein erweiterbarer SQL-Parser – entstanden aus fast 20.000 Commits seit DuckDB 1.5, laut dem DuckDB-Projekt. Die LTS-Linie wird mindestens bis Oktober 2027 unterstützt.

Wichtiger als diese Feature-Liste ist die Richtung dahinter. DuckDB begann als eingebettete analytische Datenbank: SQL läuft innerhalb einer Anwendung, auf einem Laptop oder auf einem Edge-Gerät, statt über einen dauerhaft laufenden Datenbankdienst. Version 2.0 erweitert dieses Modell, ohne es aufzugeben. Genau darin liegt aus unserer Sicht die eigentliche Geschichte.

DuckDB 2.0 betrachtet die Cloud als Ressource, nicht als Standardziel

Die aufschlussreichste Neuerung ist Quack. DuckDB kann Datenbanken nun über das Netzwerk bereitstellen, während sich ein anderer DuckDB-Client daran anbinden und Abfragen mit der neuen CONNECT-Anweisung aus der Ferne ausführen kann. Das klingt zunächst nach einer herkömmlichen Client-Server-Datenbank. Der entscheidende Unterschied: Beide Seiten bleiben vollwertige DuckDB-Instanzen. Der Client kann Berechnungen weiterhin lokal ausführen.

Das ist eine differenziertere Antwort auf Cloud-Architekturen, als einfach einen größeren gehosteten Dienst zu bauen. Ein Laptop kann Daten lokal untersuchen oder umwandeln, eine entfernte Datenbank kann zentrale Informationen verarbeiten, und die Grenze zwischen beiden lässt sich für jede Abfrage neu festlegen. Derselbe CONNECT-Mechanismus funktioniert auch mit PostgreSQL und MySQL. Ein Remote-Pushdown-Optimierer überträgt kompatible Abfragen an diese Server, anstatt ganze Tabellen über das Netzwerk zu holen.

Diese Flexibilität ist wertvoll, weil die Datenbewegung häufig die versteckten Kosten von Analysen verursacht. Alles in ein Data Warehouse zu senden, erhöht die Abhängigkeit von der Verbindung, verursacht Latenz und kann unnötige Risiken für sensible Daten schaffen. Alles lokal zu halten, kann dagegen Zusammenarbeit, Governance und zentrale Skalierung erschweren. Die Richtung von DuckDB 2.0 deutet auf einen praktischen Kompromiss hin: Berechnungen werden verschoben, wenn es sinnvoll ist – nicht, weil die Architektur davon ausgeht, dass dies zwingend nötig ist.

Die eigene Beschreibung des Projekts ist in diesem Punkt ungewöhnlich klar: DuckDB kann überall laufen – von Edge-Geräten bis zu Servern mit Hunderten von Kernen – und mit lokalen Dateien oder Objektspeicher arbeiten. Die DuckDB-Plattformseite stellt diese Portabilität als zentrale Eigenschaft dar, nicht als nachträglichen Zusatz.

Die stärkste Cloud-Funktion ist jene, die entfernte Daten lokal wirken lässt

Asynchrone Ein-/Ausgabe klingt vielleicht weniger spektakulär als ein neues Protokoll oder ein auf KI ausgerichteter CLI-Modus. Für Cloud-lastige Workloads ist sie aber wahrscheinlich die Funktion mit dem klarsten praktischen Nutzen. DuckDB 2.0 trennt das Lesen aus der Ferne von der Abfrageverarbeitung. Dadurch können mehrere Anfragen gleichzeitig ausstehen, während die CPU bereits verfügbare Daten verarbeitet.

Dieses Design zielt auf Parquet- und CSV-Dateien in einem Objektspeicher wie S3. Ein Bericht von MotherDuck beschreibt in seinem Testszenario zwei- bis dreimal schnellere Lesevorgänge über S3 – ohne Änderungen an den Abfragen. Die Werte stammen allerdings von einem einzigen Laptop und einer privaten Internetverbindung. Sie sollten daher als Hinweis aus einem Experiment verstanden werden, nicht als allgemeingültiger Benchmark. Die Analyse von MotherDuck veranschaulicht dennoch den größeren Punkt: Lokale Ausführung bedeutet nicht, die Cloud zu ignorieren. Es kann bedeuten, die Cloud als Speicher zu nutzen und einen schwergewichtigen analytischen Umweg zu vermeiden.

Hier wird DuckDBs Modell überzeugend. Ein Data Warehouse bleibt sinnvoll, wenn viele Nutzer gemeinsame, kontrollierte und kontinuierlich aktualisierte Analysen benötigen. Für einen Entwickler, der einen Datensatz untersucht, eine Anwendung, die einen Bericht erzeugt, oder ein Edge-System, das Ereignisse vor dem Upload filtert, wirkt es jedoch zunehmend übertrieben, für jede Frage die Kosten eines entfernten Clusters zu bezahlen. Das richtige Optimierungsobjekt ist nicht immer das Rechenzentrum. Manchmal ist es der Hin- und Rückweg.

VARIANT macht eingebettete Analysen fit für unordentliche Daten

Lokale Analysesysteme waren traditionell besonders attraktiv, wenn die Daten bereits sauber strukturiert waren. Echte Anwendungen sind weniger kooperativ. Protokolle entwickeln sich weiter, Ereignisdaten ändern ihre Form, und Teams müssen häufig semi-strukturierte Datensätze abfragen, bevor jemand ein perfektes Schema entworfen hat.

Der VARIANT-Typ von DuckDB 2.0 begegnet diesem Problem, indem er schemalose, typisierte Daten speichert und gleichzeitig die spaltenbasierte Ausführung beibehält. Die Engine kann häufige Strukturen erkennen und „zerlegen“, sodass wiederkehrende Felder stärker wie gewöhnliche Spalten komprimiert und ausgeführt werden. Das ist eine bedeutende Verbesserung gegenüber der Behandlung jedes JSON-Dokuments als Text – besonders bei Protokollen und Ereignisströmen, deren Struktur teils stabil und teils unvorhersehbar ist.

Der Vorbehalt ist ebenso wichtig: Das ist keine Magie. Daten mit uneinheitlichen Werttypen profitieren nicht im selben Maß wie Felder mit konsistentem Aufbau. DuckDB macht flexible lokale Analysen leistungsfähiger, beseitigt aber nicht den Bedarf an Datenmodellierung. Das ist eine Stärke, keine Schwäche. Gute Werkzeuge sollten die Kosten unvollkommener Daten senken, ohne so zu tun, als spiele Datenqualität keine Rolle mehr.

Das LTS-Label ist wichtig, weil lokale Werkzeuge Beständigkeit brauchen

Eingebettete Software lässt sich leicht übernehmen – und leicht wieder aufgeben. Ein Entwickler kann eine Bibliothek schnell in eine Anwendung integrieren. Produktivsysteme brauchen jedoch vorhersehbare Wartung, Migrationspfade und genügend Stabilität, damit sich die Entwicklung auf dieser Komponente lohnt.

Der LTS-Status von DuckDB 2.0 ist daher über das Support-Ende hinaus wichtig. Das Projekt gibt an, Version 2.0 mindestens bis Oktober 2027 zu unterstützen. Die frühere LTS-Linie 1.4 bleibt bis Ende November 2026 unterstützt, DuckDB 1.5 wurde bis März 2027 verlängert. Diese Überschneidung verschafft Teams Zeit zum Testen, statt ein großes Upgrade als Notfall behandeln zu müssen.

Darin steckt außerdem ein strategisches Signal. DuckDB ergänzt die Serveranbindung, Beobachtbarkeit und ein für Agenten geeignetes Kommandozeilenverhalten, ohne seine Identität als In-Process-Engine aufzugeben. Das Ergebnis ist kein Ersatz für ein Cloud-Data-Warehouse und sollte auch nicht als solcher vermarktet werden. Es ist eine Möglichkeit, Analysen stärker kombinierbar zu machen: heute innerhalb eines Laptops, morgen innerhalb einer Anwendung und mit zentraler Infrastruktur verbunden, wenn der Workload dies tatsächlich erfordert.

Unser Urteil ist eindeutig: DuckDB 2.0 verdient Aufmerksamkeit, nicht weil lokale Analysen grundsätzlich überlegen wären, sondern weil die geteilte Architektur schwerer von der Hand zu weisen ist. Teams sollten zentrale Data Warehouses für gemeinsame Skalierung und Governance beibehalten, DuckDB aber für Exploration, eingebettete Berichte, Edge-Verarbeitung und datenschutzsensible Analysen ernsthaft in Betracht ziehen. Die Zukunft der Datenverarbeitung wird wahrscheinlich nicht überall in größeren Clustern liegen. Sie wird in besseren Entscheidungen darüber bestehen, wohin jede einzelne Abfrage gehört.