DuckDB 2.0 legt bei Tempo zu – und die Gewinne sind an den richtigen Stellen

DuckDB 2.0 wirbt mit mehr Tempo. Das ist erst mal eine übliche Versionsbotschaft. Interessant wird es dort, wo die Beschleunigung konkrete Arbeit trifft: rekursive CTEs, halbstrukturierte Daten und Zugriffe auf Objektspeicher.

Die vorliegenden Messungen zwischen DuckDB 2.0 Alpha und Version 1.5.5 fallen teils drastisch aus. Bei rekursiven CTEs liegen die Unterschiede je nach Fall bei bis zu 90x. Beim neuen VARIANT-Typ sind Abfragen rund 6x schneller als auf JSON-Text. Für asynchrones I/O auf S3 stehen bis zu 2,4x im Raum. Das sind keine kosmetischen Zugewinne. Das sind Werte, die Modellierung und Architekturentscheidungen verschieben können.

Wo der Fortschritt wirklich zählt

Am klarsten ist der Schritt bei rekursiven CTEs. Solche Abfragen gelten schnell als Spezialfall, sind aber in Graph- und Hierarchieproblemen alltäglich: Abhängigkeitsketten, Orgbäume, Stücklisten, Berechtigungsvererbung. Wenn eine Engine hier massiv aufholt, betrifft das nicht nur ein Benchmark-Spiel. Es senkt die Hürde, solche Probleme direkt in SQL zu lösen, statt Workarounds in Python oder vorgelagerte Materialisierungen zu bauen.

Auch der VARIANT-Typ ist mehr als ein neues Datenfeature. Viele Teams schleppen JSON-Text durch Pipelines, weil er flexibel ist und schnell ins System kommt. Der Preis folgt später: langsame Auswertung, unnötiges Parsen, unklare Schemata. Wenn VARIANT in DuckDB 2.0 gegenüber JSON-Text rund sechsfach schneller arbeitet, ist die Botschaft simpel: Wer halbstrukturierte Daten ernsthaft analysiert, sollte sie nicht länger als bloßen String behandeln.

Der dritte Punkt ist asynchrones I/O auf S3. Das trifft einen echten Engpass moderner Datenarbeit. Immer mehr Analysen laufen direkt auf Dateien im Objektspeicher. Wenn eine lokale, eingebettete Analytics-Engine hier 2,4x schneller wird, ist das für Entwickler und kleine Datenteams wichtiger als jede Server-Rhetorik. Weniger Warten beim Lesen großer Parquet-Bestände bedeutet kürzere Feedback-Schleifen. Genau da gewinnt DuckDB oft seine Anhänger.

Warum das für DuckDB wichtiger ist als blanke Benchmark-Zahlen

DuckDB lebt davon, SQL-Analytics dorthin zu bringen, wo sonst Dataframes, Skripte und Ad-hoc-Jobs dominieren: auf den Laptop, in ETL-Schritte, in Notebooks, in kleine Services. In diesem Umfeld zählen rohe Spitzenwerte weniger als die Frage, ob typische Arbeit plötzlich bequem wird.

Darum sind gerade diese drei Beschleunigungen gut gewählt. Rekursive CTEs helfen bei komplexer Logik. VARIANT hilft bei schmutzigen, realen Daten. Async I/O hilft bei verteilten Dateilandschaften. Das ist keine Laborkosmetik. Das sind Baustellen, an denen Teams Zeit verlieren.

Interessant ist auch, was man daraus nicht ableiten sollte. DuckDB wird damit kein Ersatz für klassische Transaktionsdatenbanken. Wer viele konkurrierende Schreibzugriffe, langlebige Serverprozesse und hartes OLTP braucht, ist weiter in einer anderen Kategorie unterwegs. DuckDB bleibt ein Werkzeug für Analytics, ELT und explorative Datenarbeit. Genau dort wird es aber stärker.

Was Entwickler daraus mitnehmen sollten

Die wichtigste Lehre ist fast banal: Das Datenmodell entscheidet mit über die Geschwindigkeit. Wer JSON als Text ablegt, verschenkt Leistung. Wer Hierarchien oder Graph-Bezüge bisher außerhalb der Datenbank nachbaut, sollte rekursive SQL-Abfragen neu prüfen. Und wer direkt auf S3 arbeitet, bekommt mit DuckDB 2.0 mehr Luft bei I/O-lastigen Jobs.

Man muss die Zahlen trotzdem sauber lesen. Die genannten Ergebnisse stammen aus Vergleichen auf einem einzelnen Laptop zwischen 2.0 Alpha und 1.5.5. Solche Werte sind ein starkes Signal, aber kein universelles Gesetz. Workloads unterscheiden sich. Datenformen auch. Gerade deshalb ist der größere Punkt wichtiger als die exakte Multiplikation: DuckDB 2.0 verbessert genau die Pfade, die in echten Analyse-Workflows oft wehtun.

Unterm Strich ist das die richtige Art von schneller. Nicht bloß besser im Diagramm, sondern näher an den Problemen, die Leute tatsächlich haben.