Warum DuckDB meine erste Wahl für die Datenverarbeitung ist

 (robinlinacre.com)
30 Punkte von GN⁺ 2026-01-18 | 2 Kommentare | Auf WhatsApp teilen
  • DuckDB ist eine Open-Source-SQL-Engine, mit der sich große tabellarische Daten auf einer einzelnen Maschine schnell und einfach verarbeiten lassen, und wird in letzter Zeit im Data Engineering breit eingesetzt.
  • Die Installation ist einfach, es gibt keine Abhängigkeiten, und die Engine lässt sich in einer Python-Umgebung sofort ausführen, wodurch sie sich gut für CI und Testautomatisierung eignet.
  • Dank Optimierung für analytische Abfragen ist die Performance im Vergleich zu SQLite oder Postgres um bis zu das 1.000-Fache höher, und verschiedene Dateiformate (csv, parquet, json) können direkt abgefragt werden.
  • Mit benutzerfreundlicher SQL-Syntax (EXCLUDE, COLUMNS, QUALIFY, Function Chaining usw.) und einer Python-API lassen sich komplexe Pipelines effizient entwickeln.
  • Mit ACID-Konformität, Hochleistungs-UDFs und PostgreSQL-Integrations-Erweiterungen entwickelt sich DuckDB zu einer Lakehouse-Alternative für Daten im mittleren Maßstab.

Überblick über DuckDB

  • DuckDB ist eine In-Process-SQL-Engine mit Fokus auf die Optimierung analytischer Abfragen.
    • Sie läuft ohne separaten Server innerhalb der Anwendung und benötigt keinen externen Dienst wie Postgres.
    • Sie ist auf umfangreiche Join- und Aggregationsoperationen spezialisiert und bietet im Vergleich zu transaktionsorientierten Engines (OLTP) eine 100- bis 1.000-fach höhere Performance.
  • Ein zentraler Anwendungsfall ist die Batch-Verarbeitung großer Dateien wie csv, parquet und json, die direkt von der Festplatte eingelesen werden.
  • Sie kann auch für leichtgewichtige Datenexploration genutzt werden, etwa um CSV-Dateien einfach über die Kommandozeile abzufragen.

Hauptmerkmale

  • Geschwindigkeit

    • DuckDB gehört zu den schnellsten Open-Source-Engines für Datenverarbeitung und liegt in Benchmarks regelmäßig weit vorne.
    • Im Vergleich mit Polars, DataFusion, Spark und Dask ist DuckDB bei kleineren Datenmengen im Vorteil, während Spark und Dask bei sehr großen Datenmengen konkurrenzfähig sind.

  • Einfache Installation und keine Abhängigkeiten

    • DuckDB wird als einzelne vorkompilierte Binärdatei bereitgestellt und kann in Python sofort mit pip install duckdb installiert werden.
    • Durch die Abwesenheit von Abhängigkeiten ist die Installation im Vergleich zu großen Frameworks wie Spark sehr einfach.
    • In Kombination mit uv lässt sich eine Python-Umgebung in weniger als einer Sekunde einrichten.

  • CI und Tests

    • Dank schneller Startzeit und geringem Gewicht eignet sich DuckDB gut für CI- und Testumgebungen von Datenpipelines.
    • Frühere Spark-basierte Tests waren langsam und komplex, während DuckDB die Umgebungskonfiguration vereinfacht und Konsistenz mit der Produktion leichter aufrechterhalten lässt.
    Anzeige

  • Erfahrung beim Schreiben von SQL

    • Mit DuckDB lassen sich SQL-Abfragen schnell schreiben und syntaktisch prüfen.
    • Gegenüber dem lokalen Spark-Modus oder AWS Athena ist es für sofortige Ausführung und iterative Entwicklung vorteilhafter.
    • Es bietet eine UI mit Autovervollständigung.

  • Benutzerfreundliche SQL-Syntax

    • DuckDB enthält zahlreiche benutzerfreundliche SQL-Erweiterungen.
      • Unterstützt werden u. a. EXCLUDE, COLUMNS, QUALIFY, Modifikatoren für Window-Function-Aggregationen und Function Chaining (first_name.lower().trim()).
    • Diese Funktionen machen komplexe Auswahl- und Transformationsaufgaben bei Spalten deutlich kompakter.

  • Unterstützung für verschiedene Dateiformate

    • Daten können direkt aus S3, Web-URLs und lokalen Dateien abgefragt werden.
    • Für CSV bietet DuckDB Optionen zur strengen Typbehandlung, um Fehler durch unstrukturierte Eingabedaten zu vermeiden.
    Anzeige

  • Python-API

    • In Python lassen sich CTE-basierte Pipelines schrittweise definieren, und die Daten jedes Schritts können leicht überprüft werden.
      • Über Aufrufe von duckdb.sql() kann SQL in Kettenform verbunden werden.
      • Dank Lazy Execution lassen sich Zwischenergebnisse ohne Performance-Verlust prüfen.
    • Funktionen pro Schritt können getestet werden, was die Effizienz von CI-Tests verbessert.

  • ACID-Konformität

    • DuckDB bietet vollständige ACID-Garantien, auch bei der Arbeit mit großen Datenmengen.
    • Dadurch kann es als Alternative im mittleren Maßstab zu Lakehouse-Formaten wie Iceberg und Delta Lake genutzt werden.

  • Hochleistungs-UDFs und Community-Erweiterungen

    • Benutzerdefinierte Funktionen (UDFs) mit hoher Performance können in C++ geschrieben werden.
    • Über Community Extensions lassen sich Erweiterungen sofort mit Befehlen wie INSTALL h3 FROM community installieren.
      • Beispiel: Unterstützung für hexagonale Indizierung (h3) für Geodaten.

  • Dokumentation

    • Die gesamte Dokumentation wird als eine einzelne Markdown-Datei bereitgestellt, was sich gut für LLM-Training oder die Suche im Code-Editor eignet.
    • Mit Code-Folding lassen sich nur die benötigten Abschnitte leicht kopieren.
    Anzeige

Praktische Nutzung und Wirkung

  • Im Open-Source-Projekt Splink führte die Einführung von DuckDB als Standard-Backend zu folgenden Ergebnissen:
    • Weniger Nutzerprobleme, höhere Arbeitsgeschwindigkeit sowie vereinfachte Feature-Entwicklung und Tests

Bemerkenswerte Erweiterungen

  • PostgreSQL Extension: Postgres-Datenbanken können direkt aus DuckDB verbunden und abgefragt werden.
  • pg_duckdb: Bettet die DuckDB-Engine in Postgres ein, sodass Transaktions- und Analyseverarbeitung parallel möglich sind.
    • Künftig besteht nach Optimierungen bei Postgres-Indizes und Verbesserungen beim Filter Push-up das Potenzial für breite Verbreitung.

Verwandte Beiträge

2 Kommentare

 
kaydash 2026-01-18

Es ist schon ironisch, parq für verteilte Verarbeitung mit dem Ziel einzusetzen, es auf einer einzelnen Maschine zu verarbeiten.
 
GN⁺ 2026-01-18
Hacker-News-Kommentare

  • Es gibt viele Gründe, warum ich DuckDB mag
    Es unterstützt .parquet-, .json- und .csv-Dateien, und mit select * from 'tsa20*.csv' sind Glob-Reads möglich, sodass sich Hunderte von Dateien wie eine einzige behandeln lassen
    Selbst bei unterschiedlichem Schema lassen sie sich mit union_by_name leicht zusammenführen, und der CSV-Parser weist Typen automatisch zuverlässig zu
    Die WebAssembly-Version ist 2 MB groß, die CLI 16 MB, also sehr klein
    Dadurch kann man es direkt in Produkte einbetten. Zum Beispiel wie bei Malloy
    Malloy ist so etwas wie eine technische Version von PowerBI oder Tableau und nutzt semantische Modelle, damit KI bessere Queries schreiben kann. Es fühlt sich an, als würde SQL 10-mal einfacher werden

    • Dank der CSV-Unterstützung von DuckDB hat sich meine Art der Datenexploration komplett verändert
      Früher habe ich viel Zeit darauf verwendet, zuerst das Schema zu verstehen, heute lade ich die Daten, schreibe explorative Queries, überprüfe Annahmen und wiederhole dann den Prozess aus Bereinigung, Transformation und Tabellenerstellung
      So kann ich viel schneller tief einsteigen und Sackgassen früh erkennen, was Zeitverschwendung reduziert
      Ich habe gehört, dass es ein Paper über die Funktionsweise des CSV-Parsers und mögliche zukünftige Verbesserungen gibt, habe es aber noch nicht gefunden
    • Ich habe zuletzt viel mit ClickHouse gearbeitet, das viele ähnliche Vorteile wie DuckDB hat
      Vor allem die Parquet- und JSON-Ingestion ist praktisch, und clickhouse-local ähnelt dem Konzept, DuckDB einzubetten
      Mit SELECT ... FROM s3Cluster(...) ist Wildcard-Ingestion aus S3-Buckets möglich, verteilt über die Cluster-Knoten
      schema_inference_mode wird anscheinend ebenfalls unterstützt
      ClickHouse hat auch eine Funktion ähnlich union_by_name umgesetzt
      Relevante Doku: s3Cluster-Funktion, Schema Inference, PR #55892
    • Ich habe Shaper gebaut, das wie die Idee von Malloy Datenabfragen und Visualisierung kombiniert
      Shaper verwendet allerdings SQL statt einer eigenen Sprache
      Auf Basis von DuckDB lassen sich Dashboards nur mit SQL bauen
      Shaper GitHub
    • Ich habe ZenQuery gebaut und nutze DuckDB für die interne Verarbeitung
      Die Geschwindigkeit ist erstaunlich, und die automatische Schemaerkennung funktioniert meistens korrekt
      Ein LLM erzeugt aus natürlichsprachlichen Anfragen das richtige SQL
    • Das ist wirklich eine hervorragende Einführung
      Ich habe früher SQLite mit manuellem Import verwendet, aber mit DuckDB ist alles viel einfacher geworden

  • Ich nutze DuckDB ebenfalls sehr gern
    Ich arbeite mit Wissenschaftlern zusammen, die die Küstenumwelt von British Columbia erforschen, und wir verarbeiten riesige Datenmengen, von Gletscherbeobachtungen bis zu Tiefsee-Drohnendaten
    Wir haben DuckDB als Engine für ein neues Transformationswerkzeug für Biodiversitätsdaten gewählt; Ziel ist es, Daten in den Darwin-Core-Standard zu transformieren und zu validieren
    Wir erzeugen DuckDB-Tabellen dynamisch anhand von Schemata und importieren die Daten. Bei Fehlern wird zeilenweise der Grund ausgegeben
    Transformation und Validierung laufen ebenfalls komplett innerhalb von DuckDB
    Dadurch konnten wir eine viel schnellere, leistungsfähigere und sogar im Browser ausführbare Anwendung bauen
    Feldforscher können sie offline im iPad-Browser verwenden
    Mit DuckDB habe ich das Vertrauen, dass SQL die harte Arbeit übernimmt
    Fehlende Typsicherheit gleichen wir durch Parsing und Tests aus
    Ziel des Projekts ist es, Wissenschaftlern zu ermöglichen, Biodiversitäts- und Genomikdaten mit gemeinsamen Werkzeugen zu analysieren und in öffentlichen Repositorien zu veröffentlichen

    • Mich würde interessieren, in welchem Format die bestehenden Datensätze vorliegen
      Ich arbeite in der wissenschaftlichen Datenverarbeitung häufig mit HDF5, aber DuckDB unterstützt HDF5 nicht nativ
      Die vorhandene Erweiterung war langsam und funktional eingeschränkt, daher habe ich mit C++-Templates eine neue Erweiterung gebaut
      Ich suche Leute mit Interesse an einer Zusammenarbeit
    • Mich würde interessieren, welche Vorteile Polars für dieselbe Aufgabe hätte
      Persönlich finde ich die Syntax von Polars viel angenehmer als SQL und frage mich, ob sich DuckDB für mich lohnt

  • Wir verwenden DuckDB für die Analyse und Feed-Verarbeitung bei Bluesky
    Um Ergebnisse schnell zu erhalten, nutzen wir das Apache-Arrow-Interface und erzeugen mit SQG direkt Code aus DuckDB-SQL-Queries

    • Mich würde der Tech-Stack interessieren. Ich würde gern wissen, ob es einen Artikel über die interne Struktur gibt. Auch das HN-Tool ist beeindruckend

  • Ich möchte das Java-Projekt manifold-sql vorstellen
    Damit lässt sich DuckDB-SQL typsicher inline schreiben
    Man kann SQL direkt in den Code einbetten und mit .fetch() über die Ergebnisse iterieren, was ohne Zwischenschicht sehr sauber ist

  • Die Aussagen des Autors sind für grundlegende Datenverarbeitung plausibel,
    aber der Teil „Die meisten Tabellendaten lassen sich auf einer einzelnen Maschine verarbeiten“ ist diskussionswürdig
    Bei Skalierung, Pivoting oder Anreicherung von Daten läuft man schnell in Out-of-Memory (OOM)
    Auch die Aussage „SQL sollte die erste Wahl für modernes Data Engineering sein“ passt nicht gut zu komplexeren Analysen

    • Hier der Autor selbst
      Dataframe-APIs wie Polars oder pandas haben ebenfalls viele Vorteile, aber das Ökosystem ist nicht standardisiert, weshalb man Pipelines oft neu schreiben muss
      Die meisten Daten liegen unter 10 GB, daher lassen sie sich auf einer einzelnen Maschine gut verarbeiten
      Spark wird oft übertrieben eingesetzt
      Mein Standpunkt ist: „Probier es zuerst mit DuckDB.“ In einfachen Fällen ist es schnell und effizient
    • Für fortgeschrittene Analysen wie ML oder Visualisierung sind Dataframes besser geeignet
      Für einfache Pipeline-Verarbeitung ist SQL gut, aber Lesbarkeit ist subjektiv
      Ich persönlich finde die Dataframe-Seite deutlich leichter lesbar
    • SQL ist nach wie vor leicht zu lernen, und Datenmodellierung geschieht größtenteils in SQL
      Beim Thema Ingestion wird viel Python oder Scala verwendet, aber SQL wird nicht verschwinden
    • Ich verarbeite 500 GB Parquet-Daten mit DuckDB, und selbst auf einem Desktop mit 50 GB RAM läuft es flüssig und schnell
      OOM scheint nur in Extremfällen ein Problem zu sein
    • Polars hat die meisten dieser Vorteile ebenfalls und unterstützt sogar GPU- und verteilte Backends
      So viel Aufmerksamkeit DuckDB auch bekommt, Polars wird gleichzeitig unterschätzt

  • Ich mache viel Datenverarbeitung und nutze hauptsächlich Polars
    Es ist sehr schnell und bietet wie pandas viele Funktionen, die sich in SQL nur schwer ausdrücken lassen
    Man kann auch direkt Python-Funktionen verwenden
    Selbst wenn DuckDB bei der Performance gleichauf wäre, zögere ich wegen der Ausdrucksbeschränkungen von SQL

    • Nach meiner Erfahrung war DuckDB viel schneller und kompakter
      Es ist eigenständig, einfach zu installieren und erfordert kaum Tuning oder Lernaufwand

  • Ich habe mit DuckDB eine schlecht formatierte Excel-Datei geladen, die von einem Mainframe erzeugt wurde,
    und mit der Option all_varchar war sie in weniger als einer Sekunde geladen
    Excel selbst ist noch dabei, die Datei zu öffnen

  • DuckDB ist hervorragend, aber dynamisches Laden von Extensions kollidiert mit Code-Signing und macht den Einsatz in kommerziellen Apps schwierig
    Außerdem verwendet die Spatial-Extension LGPL-Komponenten, was Lizenzfragen aufwirft
    Es wäre gut, wenn man wie bei Apache Arrow nur die benötigten Funktionen paketweise kombinieren könnte
    Zum Beispiel: GB/s-Array-Übertragung per HTTP mit Arrow Flight, Dateifreigabe mit Arrow IPC, Parquet-Lesen als separates Trait
    DuckDBs SQL-Typsystem unterscheidet sich von Arrow, was zu Typinkompatibilitäten führen kann
    Arrow stellt für die meisten Sprachen native Bibliotheken bereit

  • Ich frage mich, ob man bei einer einzelnen Tabelle mit mehreren Milliarden Transaktionsdaten und 30 Spalten
    Seiten, die mit WHERE-Bedingungen gefiltert sind, schnell abrufen kann
    In Postgres dauert selbst ein einfaches count(*) lange

    • Bei dieser Größenordnung sollte das auch in DuckDB innerhalb weniger Sekunden erledigt sein
      Langsam wurde es bei mir nur bei komplexen Joins oder beim Glob-Verarbeiten vieler Dateien
    • Um count zu beschleunigen, könnte periodisches Caching sinnvoller sein als Indizes
      Wenn die WHERE-Bedingungen einfache Spalte-Wert-Paare sind, sollte das ziemlich schnell gehen

  • DuckDB ist nicht einfach nur eine schnelle DB, sondern bietet auch eine hervorragende Developer Experience (devx)
    Der Einstieg ist leicht, wodurch das Ökosystem schnell wächst
    Auch die Web-/WASM-Integration ist beeindruckend
    Ich hoffe, dass mehr solcher kleinen Engines auftauchen und Wettbewerb sowie Innovation weiter antreiben