Hannes Mühleisen ist Mitschöpfer von DuckDB und CEO von DuckDB Labs. Zusammen mit Mark Raasveldt hat er DuckDB ursprünglich als Forschungssprojekt am Centrum Wiskunde & Informatica (CWI) Amsterdam ins Leben gerufen.

Golo: Hannes, du bist einer der Mitschöpfer von DuckDB und Mitgründer von DuckDB Labs. Als DuckDB im Sommer 2024 in Version 1.0 erschienen ist, habe ich für heise darüber berichtet – und seitdem ist viel passiert. Bevor wir in die Details gehen, würde ich gerne ganz am Anfang beginnen: DuckDB hat seine Wurzeln in eurer Forschung am CWI in Amsterdam, wo du und Mark Raasveldt jahrelang an Datenbank-Internas gearbeitet habt. Was war der Moment (oder die Lücke), an dem ihr beide entschieden habt, dass die Welt tatsächlich noch eine weitere Datenbank benötigt, und was sollte sie ursprünglich sein?

Hannes: Wir haben damals recht eng mit Statistikern zusammengearbeitet, die große Umfragedaten auswerten mussten. Für uns war klar, die brauchen Datenbank-Technologie! Aber als wir das vorgeschlagen haben, haben die gesagt, dass sie eigentlich keine Lust auf eine Datenbank im klassischen Sinne haben. Es war zum Beispiel vor Docker nicht einfach, eine Datenbank lokal zu installieren, ohne Experte zu sein. Außerdem konnte man den Zustand der Datenbank auch nicht ohne weiteres mit jemand anderem teilen.

Es war klar, dass eine neue Architektur notwendig ist, ein eingebettetes analytisches Datenbanksystem. Das gab es damals noch gar nicht. Es war recht schnell klar, dass wir eine komplette Neuentwicklung brauchten – ein sauberes Design, das auf das eingebettete Einsatzmodell zugeschnitten war, mit einer modernen Systemarchitektur.

Im Sommer 2018 beschlossen wir, dies in die Tat umzusetzen, und begannen mit der Implementierung von DuckDB.

Der Begriff „SQLite for Analytics“ haftet DuckDB schon seit Jahren an. Er bringt vieles in nur drei Worten auf den Punkt, kann aber auch reduzierend wirken. Wie treffend findest du dieses Framing aus deiner heutigen Sicht, und wo greift es zu kurz?

Hannes: „SQLite für Analytics“ war in den ersten fünf Jahren eine treffende Beschreibung des Projekts. Im Laufe der Zeit haben wir einen leistungsfähigen Erweiterungsmechanismus hinzugefügt, der die Arbeit mit nahezu jedem Dateiformat wie Parquet, JSON oder Iceberg und vielen gängigen Speicheroptionen, zum Beispiel S3-API, ermöglicht. Deshalb haben wir begonnen, DuckDB als universelles Datenwerkzeug zu bezeichnen.

Das ist vielleicht weniger einprägsam als die ursprüngliche Beschreibung, erfasst aber, dass das System inzwischen wesentlich vielseitiger ist. Und wenn man ein SQLite für Analytics braucht, kann man DuckDB nach wie vor dafür verwenden.

Jenseits von Big Data

Du vertrittst seit einiger Zeit die Position, dass verteilte Systeme für die allermeisten analytischen Workloads schlicht überdimensioniert sind – und dass eine einzelne moderne Maschine deutlich mehr leisten kann, als die Branche meist annimmt. Das ist ein Argument, das ich auch in einem ausführlichen iX-Test aufgegriffen habe, in dem ich DuckDB als schlanke Alternative zu Apache Spark positioniert habe. Magst du diese These in deinen eigenen Worten machen? Und wie reagierst du auf Leute, die dich daraufhin sofort dafür kritisieren, ihr Problem zu unterschätzen?

Hannes: Mein Argument stützt sich auf drei Säulen. Erstens: Die Hardwareentwicklung hat große Fortschritte gemacht, und moderne Computer sind erstaunlich leistungsfähig. Heute wird ein leistungsstarker Laptop mit einem Dutzend schneller CPU-Kerne, mehreren zehn Gigabyte Arbeitsspeicher und einer schnellen SSD mit Terabytes an Speicherplatz ausgeliefert. Ein Server kann leicht das Zehnfache und mehr bieten.

Zweitens: Das Feld der Datenbankarchitektur hat sich seit 2010 – als Big Data aufkam – erheblich weiterentwickelt. Wir konnten auf Ergebnisse zu spaltenbasierter Speicherung, vektorisierter Abfrageverarbeitung, Parallelität und Nebenläufigkeitskontrolle aufbauen. Darüber hinaus haben wir eigene Forschung zu Themen wie Kompression und Operatoren für Datenmengen, die den Arbeitsspeicher übersteigen, betrieben.

Drittens: Was die meisten nicht bedenken – auch wenn eine Organisation auf Petabytes an Daten sitzt, muss man nie alle Daten in einer einzigen Abfrage verarbeiten. Dafür gibt es inzwischen belastbare Belege: In den letzten Jahren haben sowohl Snowflake als auch Redshift Stichproben und Statistiken ihrer Benutzerabfragen veröffentlicht – wahre Fundgruben, um reale Workloads zu verstehen. George Fraser von Fivetran hat eine hervorragende Analyse dazu vorgestellt, in der er zeigt, dass selbst unter den Abfragen auf Snowflake und Redshift das 99,9-Perzentil etwa 300 GB scannt und somit problemlos auf einem einzelnen Knoten laufen könnte.

Performance ist einer der auffälligsten Aspekte von DuckDB – viele Erstanwender beschreiben ihre erste Erfahrung mit den Worten „das kann nicht stimmen, lass mich das Ergebnis nochmal prüfen“. Welche architektonischen Entscheidungen sind dafür aus deiner Sicht am wichtigsten, und welche davon sind für Außenstehende nicht offensichtlich?

Hannes: Wir haben bereits über die Entscheidung für eine Einzelknoten-Architektur gesprochen, die verschiedene Arten von Overhead in Implementierung, Betrieb und Leistung eliminiert. Aber es gibt auch einige nicht triviale architektonische Entscheidungen.

Wir haben uns für vektorisierte Ausführung statt JIT-Kompilierung entschieden, weil sie perfekt für analytische Workloads und langfristig deutlich einfacher zu warten ist. Wir haben keine GPUs oder exotische Hardware wie KI-Beschleuniger eingesetzt, sondern all unsere Energie darauf verwendet, die effizientesten Algorithmen für die CPU zu schreiben. Und schließlich haben wir bei der Implementierung dieser Algorithmen bewusst auf SIMD-Intrinsics (manuell ausformulierte Vektorbefehle) verzichtet. Stattdessen haben wir skalaren Code geschrieben und den Compiler die Auto-Vektorisierung übernehmen lassen. Das Ergebnis ist hoch portabler und zugleich leistungsfähiger Code.

Darüber hinaus – wie in der vorherigen Frage besprochen – sind viele aktuelle Forschungsergebnisse in DuckDB eingeflossen. Die Verarbeitung von Datenmengen, die den Arbeitsspeicher übersteigen, durch Auslagerung auf die Festplatte trägt maßgeblich zur Leistung von DuckDB bei. Die meisten modernen Datenbanksysteme können auf die Festplatte auslagern, aber wenn sie es tun, erleben sie einen Performance-Absturz. DuckDB nutzt moderne Flash-basierte Speicher, um dies wesentlich eleganter zu handhaben – oft bemerken die Benutzer kaum, dass ihre Abfragen auf die Festplatte ausgelagert wurden.

Das Ökosystem

Die Reichweite von DuckDB in die Python- und R-Communities, in Node.js, in alle möglichen Tools und Notebooks ist bemerkenswert. War diese Ökosystem-Strategie von Anfang an bewusst gewählt, oder ist sie entstanden, weil die Leute DuckDB in ihre Workflows hineingezogen haben?

Hannes: Man muss die Anwender natürlich da abholen, wo sie sind. Am Anfang stellten wir uns vor, dass DuckDB für Data-Science-Workloads genutzt werden würde, und das bestimmte die erste Auswahl an Clients. Wir brauchten natürlich einen Kommandozeilen-Client. Auf der Sprachseite war Python bereits sehr stark, und wir hatten enge Verbindungen zur R-Community, also entschieden wir uns, diese Clients zuerst zu implementieren.

Node.js folgte bald darauf. Als DuckDB wuchs, begann die Community eigenständig Clients zu entwickeln. Das ermöglichte es uns, deren Akzeptanz zu beobachten, bevor wir die Arbeit des Kernteams in fünfzehn verschiedene Treiber investierten. Zum Beispiel wurde der DuckDB-Go-Treiber zunächst von Marc Boeker implementiert, der den Code später an die DuckDB Foundation übergab.

Der Extension-Mechanismus wirkt wie eine eher leise, aber sehr folgenreiche Designentscheidung. Er erlaubt DuckDB, Formate zu lesen, für die es nicht gebaut wurde, mit Object Stores zu arbeiten und sogar mit anderen Datenbanken zu sprechen. Wie denkst du über die Grenze zwischen dem, was in den Kern gehört, und dem, was in einer Extension besser aufgehoben ist?

Hannes: Wir sehen, dass DuckDB in ressourcenbeschränkten Umgebungen eingesetzt wird – Einplatinencomputer, Browser-Tabs, Container mit begrenztem Arbeitsspeicher. Um diesen Einsatz zu ermöglichen, wollen wir den Kern von DuckDB kleinhalten und nur das Wesentliche einbauen: den SQL-Parser, die Datenbank-Engine, die Speicher-Engine, den CSV-Reader – und den Erweiterungsmechanismus. Die meisten anderen Funktionen wie der Parquet-Reader oder sogar HTTPS-Unterstützung stehen als Erweiterungen zur Verfügung.

Ein schöner Nebeneffekt dieses leistungsfähigen Erweiterungsmechanismus ist, dass unsere Community eigene Erweiterungen bauen kann. Derzeit gibt es mehr als 180 Community-Erweiterungen für DuckDB, die jeweils neue Funktionen ins System bringen und sich mit einer einzigen Zeile installieren lassen.