DuckDB 2.0 kann jetzt als Server laufen. Wann das Ihren Stack verändert – und wann nicht.

DuckDB hat am 21. Oktober Version 2.0.0 veröffentlicht – die größte Version in der Geschichte des Projekts und der Beginn einer neuen Long-Term-Support-Linie mit dem Codenamen „Cinnamon Teal“. Die Schlagzeile: DuckDB, von Anfang an eine In-Process-Datenbank, kann jetzt als Server betrieben werden. Eine überarbeitete Version des Quack-Protokolls erlaubt es einem DuckDB-Prozess, seine Datenbanken über das Netzwerk bereitzustellen, und ein neues CONNECT-Statement lässt eine andere Session sich verbinden und Abfragen dorthin weiterleiten. Das Kommandozeilenwerkzeug erhielt -serve und -connect als Shortcuts dafür. CONNECT funktioniert auch mit PostgreSQL und MySQL, wo ein neuer Pushdown-Optimierer die Abfrage an den Remoteserver sendet, anstatt ganze Tabellen über das Netzwerk zu übertragen.

In der Box steckt noch viel mehr. Asynchrones I/O beschleunigt Lesevorgänge von S3 und anderen Objektspeichern erheblich. Ein erstklassiger VARIANT-Typ verarbeitet halbstrukturierte Daten. Es gibt Trigger, einen PEG-basierten SQL-Parser, den Erweiterungen um neue Syntax ergänzen können, und ein neues Standardspeicherformat. All das stammt aus knapp 20.000 Commits seit DuckDB 1.5.

Der Servermodus ist optional. Behandeln Sie ihn auch so.

Der gesamte Reiz von DuckDB war, dass kein Server betrieben werden musste. Sie betten ihn ein, zeigen auf einige Parquet- oder CSV-Dateien und erhalten spaltenorientierte Analysen im eigenen Prozess. Der 2.0-Servermodus ändert diesen Standard nicht, und die meisten Teams sollten ihn nicht am ersten Tag einsetzen. Die eingebettete Engine ist nach wie vor das richtige Werkzeug für die überwiegende Mehrheit analytischer Workloads. Der Netzwerkmodus ist für den engen Anwendungsfall gedacht, in dem mehrere Clients eine einzige Live-Instanz wirklich gemeinsam nutzen müssen.

Aus unserer PHP- und Docker-Entwicklungsarbeit mit datenschweren Anwendungen haben wir beobachtet, wie Teams ein separates Postgres-Replikat oder ein ganzes Warehouse aufgesetzt haben, um einen Reporting-Screen zu unterstützen, der wirklich nur eine Handvoll Dateien abgefragt hat. Eingebettetes DuckDB hätte diese Aufgabe ohne zusätzliche Infrastruktur erledigt. Das neue asynchrone I/O ist hier das stille Upgrade. Es macht die S3-gestützte Variante dieses Musters schnell genug, dass mittelgroßes Reporting keinen eigenen Datenbankserver mehr benötigt. Wenn Sie cloudnative Apps auf AWS entwickeln, entfällt damit ein bewegliches Teil.

Das In-Process-Modell ist auch anderswo gut einsetzbar. In unseren nativen iOS- und Android-Projekten, besonders bei Offline-First-Apps im Gesundheitswesen und IoT, bedeutet On-Device-Analytik meist das manuelle Erstellen von Abfragen über SQLite oder das Senden von Daten an ein Backend zur Verarbeitung. Eine analytische Engine, die offline innerhalb der App läuft, passt besser zu dieser Arbeit als beide Optionen. Das ist die Art von Architekturentscheidung, die wir häufig in unserer Kundenarbeit treffen.

Wo ich bremsen würde: Quack exponieren

Der Servermodus ist der Teil, der mich beunruhigt. Standardmäßig lauscht der Quack-Server nur auf localhost, was die richtige Entscheidung ist. Die Dokumentation ist klar, dass die Option allow_other_hostname, die ihn direkt freigibt, „nur für Tests gedacht“ ist. Wenn Sie echten Remotezugriff möchten, halten Sie den Server auf localhost und stellen Sie einen TLS-terminierenden Reverse-Proxy davor. Bei unseren Pentesting-Engagements ist dies eine der häufigsten Arten, wie ein Dienst kompromittiert wird: Er wird mit einer sicheren Standardkonfiguration ausgeliefert, jemand ändert eine bequeme Einstellung, damit eine Demo funktioniert, und schon ist der Dienst unauthentifiziert auf einer öffentlichen IP erreichbar. Behandeln Sie einen Quack-Port wie jeden anderen Datenbankport. Verwenden Sie das Token, terminieren Sie TLS an einem Proxy und exponieren Sie ihn niemals direkt ins Internet.

Die Upgrade-Falle ist das Speicherformat

Die eine breaking Change, die Menschen treffen wird, ist das Speicherformat. Standardmäßig schreibt 2.0 ein neues Format, das DuckDB-Versionen vor 2.0 nicht lesen können. Die andere Richtung ist in Ordnung. Version 2.0 liest und schreibt Ihre bestehenden Dateien, und diese bleiben für ältere Versionen lesbar. Das Problem sind gemischte Flotten. Sobald ein 2.0-Prozess eine Datenbank im neuen Format erstellt oder überschreibt, schlägt jedes ältere DuckDB, das diese Datei berührt, mit einem Versionsfehler fehl. Wenn Sie viele DuckDB-Prozesse mit unterschiedlichen Versionen betreiben, ist das ein Koordinationsproblem und kein einzeiliger Bump.

Bevor Sie also irgendetwas upgraden, prüfen Sie, von wo Ihre DuckDB-Dateien gelesen werden und von welchen Versionen. Wenn zwei Dienste eine Datei teilen und nur einer auf 2.0 wechselt, bricht der erste Schreibvorgang der aktualisierten Seite den anderen in der Produktion. Pinnen Sie DuckDB-Versionen in Ihren Dockerfiles und Lockfiles, upgraden Sie die Schreiber zuletzt und behalten Sie ein Fallback auf der alten Linie, während Sie testen. Das DuckDB-Team empfiehlt, 2.0 zunächst auf einem Schattensystem auszuprobieren, und sagt, dass geschäftskritische Workloads auf den ersten Patch warten sollten, der im November erwartet wird. Das ist ein vernünftiger Rat. Beachten Sie auch die Fristen für ältere Linien: Der Support für 1.4 endet am 17. November, und 1.5 wurde bis März 2027 verlängert, um den Menschen ausreichend Zeit zu geben.

Warum das LTS-Label wichtig ist

Noch eine Sache, die Teams mit Auditoren im Raum beachten sollten. Version 2.0 ist ein LTS-Release, der bis mindestens Oktober 2027 unterstützt wird. Für unsere Schweizer Unternehmenskunden mit Compliance-Anforderungen ist „unterstützt bis zu einem bestimmten Datum“ oft der Unterschied zwischen einer Abhängigkeit, die eine Prüfung besteht, und einer, die es nicht tut. Das ist ein echter Grund, die LTS-Linie gegenüber jedem Feature-Release zu bevorzugen.

Wenn es vertraut klingt, Analysen in ein Produkt zu integrieren, ohne ein ganzes Warehouse aufzubauen, oder einen neuen Datendienst vor dem Launch abzusichern, sprechen wir.