---
title: "DuckDB erklärt: Wann eine Datenbank auf dem Laptop SQLite, Polars und BigQuery schlägt"
description: "DuckDB ist eine In-Process-SQL-Datenbank für Analysen: kein Server, spaltenorientiert, vektorisiert, und sie liest Parquet, CSV und S3 direkt. Was DuckDB ist, ein nachvollziehbarer Benchmark gegen SQLite, pandas und Polars mit 11,2 Millionen Taxifahrten, wo DuckDB BigQuery schlägt und wo nicht, dazu Quack, DuckLake, MotherDuck und DuckDB 2.0."
author: Aleksei Aleinikov
date: 2026-10-20
lang: de
tags: [duckdb, duckdb-vs-sqlite, polars, parquet, motherduck, bigquery, data-engineering]
canonical: https://www.alekseialeinikov.com/de/blog/topics/data/duckdb-erklaert-vs-sqlite-polars-bigquery
source: alekseialeinikov.com
---

# DuckDB erklärt: Wann eine Datenbank auf dem Laptop SQLite, Polars und BigQuery schlägt

Ein Jahrzehnt lang galt eine einfache Regel: Kleine Daten kommen in pandas, große in ein Data Warehouse, und alles dazwischen bekommt einen Spark-Cluster, den niemand pflegen will. **DuckDB** hat diese Regel leise gebrochen. Es ist eine vollwertige analytische SQL-Datenbank, die sich per `pip` installiert, in deinem Python-Prozess läuft und einen Ordner voller Parquet-Dateien schneller abfragt, als das Warehouse der meisten Teams eine Dashboard-Kachel liefert.

Genau deshalb wird DuckDB leicht überschätzt. Es ist kein BigQuery-Killer und auch kein schnelleres SQLite für deine App. Es ist etwas Spezifischeres, und sobald du seine Grenzen kennst, wird es zu einem der nützlichsten Werkzeuge im Datenstack. Dieser Leitfaden erklärt, was DuckDB ist, zeigt einen Benchmark, den du selbst wiederholen kannst, und zieht die Linie zwischen „nimm DuckDB“ und „du brauchst weiterhin das Warehouse“.

![DuckDB: die analytische Datenbank, die in deinem Prozess läuft.](https://www.alekseialeinikov.com/blog/duckdb-explained.webp)

## Was DuckDB eigentlich ist

DuckDB ist eine **In-Process-OLAP-Datenbank**. Jedes dieser Wörter zählt:

- **In-Process.** Es gibt keinen Server. DuckDB ist eine Bibliothek, die in dein Programm eingebunden wird: Python, R, Node.js, Java, Go, Rust, die CLI, per WebAssembly sogar der Browser. Eine Datenbank ist eine einzige Datei oder liegt nur im Speicher. Nichts zu deployen, kein Port, kein Connection-Pool.
- **OLAP.** DuckDB ist für analytische Abfragen gebaut: Millionen Zeilen scannen, filtern, joinen, gruppieren, aggregieren. Daten werden **spaltenweise** gespeichert. Eine Abfrage, die fünf von hundert Spalten braucht, liest nur diese fünf.
- **Vektorisiert.** Statt Zeile für Zeile arbeitet die Engine auf Blöcken von Werten pro Spalte. Das hält die CPU-Caches gefüllt und nutzt alle Kerne.

DuckDB stammt aus der Datenbankforschung am CWI in Amsterdam, entwickelt von Mark Raasveldt und Hannes Mühleisen, erstmals 2019 veröffentlicht. Es steht unter der MIT-Lizenz und wird von der gemeinnützigen DuckDB Foundation verwaltet. Im August 2026 überschritt das Projekt 40.000 GitHub-Sterne, und im selben Monat kündigte DuckLabs, die Firma hinter der Entwicklung, an, [zu AWS zu wechseln](https://duckdb.org/2026/08/26/ducklabs-to-join-aws.html), mit dem ausdrücklichen Versprechen, dass DuckDB, DuckLake und Quack unter der Foundation MIT-lizenziert bleiben.

Die beste Kurzbeschreibung ist immer noch die alte: **DuckDB ist SQLite für Analysen.**

![In-Process vs. Client-Server: Ein klassisches Warehouse sitzt hinter Netzwerk und Server, DuckDB läuft im Anwendungsprozess und liest Parquet, CSV und S3 direkt.](https://www.alekseialeinikov.com/blog/duckdb-in-process.webp "Kein Server, kein Netzwerk-Hop: Die Query-Engine lebt in deinem Prozess und liest Dateien dort, wo sie liegen.")

## In fünf Minuten zur ersten Abfrage

Am schnellsten verstehst du DuckDB, wenn du es auf eine Datei richtest, die du ohnehin hast.

```bash
pip install duckdb
```

```python title="taxi.py"
import duckdb

# Parquet-Dateien direkt abfragen: kein CREATE TABLE, kein Ladeschritt.
duckdb.sql("""
    SELECT payment_type, count(*) AS trips, avg(total_amount) AS avg_total
    FROM 'yellow_tripdata_2025-0*.parquet'
    GROUP BY payment_type
    ORDER BY trips DESC
""").show()
```

Was beim ersten Mal überrascht:

- **Dateien sind Tabellen.** `FROM 'data/*.parquet'`, `FROM 'export.csv'` und `FROM 'events.json'` funktionieren, mit Globbing und automatischer Schema-Erkennung.
- **DataFrames sind auch Tabellen.** Liegt ein pandas- oder Polars-DataFrame namens `df` im Scope, fragt `duckdb.sql("SELECT ... FROM df")` ihn direkt ab, und `.df()` oder `.pl()` macht aus dem Ergebnis wieder einen.
- **Remote-Speicher ist nur ein Pfad.** Mit der Erweiterung `httpfs` funktioniert `FROM 's3://bucket/events/*.parquet'` oder eine GCS- bzw. HTTPS-URL genauso, und DuckDB liest nur die Spalten und Row-Groups, die es braucht.
- **Es spricht Lakehouse.** Erweiterungen lesen und schreiben Iceberg- und Delta-Tabellen und binden PostgreSQL-, MySQL- und SQLite-Datenbanken ein. Eine einzige SQL-Abfrage kann so eine Postgres-Tabelle mit Parquet auf S3 joinen.

Im Terminal macht die `duckdb`-CLI dasselbe, und `duckdb -ui` öffnet eine lokale Web-Oberfläche im Notebook-Stil.

## Der Benchmark: 11,2 Millionen Taxifahrten auf dem Laptop

Aussagen wie „100-mal schneller“ sind billig, deshalb hier ein Test zum Nachmachen. Die Daten sind die öffentlichen Yellow-Taxi-Fahrten der New Yorker TLC von Januar bis März 2025: drei Parquet-Dateien, 189 MB, **11.198.026 Fahrten**. Drei Fragen, die jede Analystin stellen würde:

1. **Q1:** Fahrten und durchschnittlicher Betrag pro Zahlungsart (ein Group-by).
2. **Q2:** Fahrten und durchschnittliche Strecke pro Tagesstunde, ohne Fahrten mit Strecke null (Filter, Zeitstempel-Funktion, Group-by).
3. **Q3:** Die 10 umsatzstärksten Abholzonen (Join mit der Zonentabelle mit 265 Zeilen, Group-by, Sortierung).

Jede Engine lief in einem eigenen Prozess auf demselben Laptop. Jede Abfrage lief viermal; die Tabelle zeigt den Median der letzten drei Läufe. Alle Engines lieferten identische Ergebnisse (7.484.734 Kartenzahlungen mit durchschnittlich 28,47 $; JFK Airport vorn mit 31,4 Millionen $).

| Engine | Ladeschritt | Q1 | Q2 | Q3 | Speicher (Spitze) |
|---|---|---|---|---|---|
| **DuckDB 1.5.6** (SQL auf Parquet) | keiner | **16 ms** | **36 ms** | **44 ms** | **237 MB** |
| Polars 1.36 (lazy, `scan_parquet`) | keiner | 19 ms | 128 ms | 305 ms | nicht gemessen |
| Polars 1.36 (eager, Daten im RAM) | 0,07 s | 10 ms | 127 ms | 351 ms | 3,3 GB |
| pandas 2.3 (Daten im RAM) | 1,5 s | 126 ms | 347 ms | 661 ms | 3,4 GB |
| SQLite 3.53 (Tabelle auf Disk) | 19,8 s | 1.800 ms | 3.584 ms | 4.529 ms | 52 MB |

![Benchmark mit 11,2 Millionen New Yorker Taxifahrten: DuckDB antwortet in 16–44 ms mit 237 MB Speicher, Polars in 10–351 ms, pandas in 126–661 ms mit 3,4 GB, SQLite in 1,8–4,5 s.](https://www.alekseialeinikov.com/blog/duckdb-benchmark.webp "Dieselben drei Fragen, dieselben Antworten. DuckDB ist bei jeder Abfrage mit Join oder Zeitstempel am schnellsten und die einzige schnelle Engine, die die Daten nicht im RAM braucht.")

Was die Zahlen ehrlich sagen:

- **DuckDB vs. SQLite: etwa 100-mal schneller.** Nicht weil SQLite schlecht ist, sondern weil es ein Zeilenspeicher für Transaktionen ist. Jede analytische Abfrage liest jede Spalte jeder Zeile. SQLite brauchte wenig Speicher, weil es von der Platte streamte, musste die Daten aber erst 20 Sekunden lang in eine 529-MB-Datei laden.
- **DuckDB vs. pandas: 8- bis 15-mal schneller, ein Fünfzehntel des Speichers.** pandas muss erst alle 11 Millionen Zeilen in den RAM holen (1,5 s, 3,4 GB). DuckDB streamt die Parquet-Dateien und hält nie den ganzen Datensatz.
- **DuckDB vs. Polars: gleichauf bei Einfachem, vorn bei Joins.** Polars lag bei Q1 gleichauf und ist eine hervorragende DataFrame-Bibliothek. Bei Q2 und Q3 war DuckDB in diesem Setup 3,5- bis 7-mal schneller. Deine Abfragen können anders aussehen; die ehrliche Erkenntnis ist, dass beide in einer anderen Liga spielen als pandas.

Die Speicherspalte ist die wichtigste. Ein Laptop mit 16 GB kann keine 50 GB in pandas laden, aber DuckDB fragt sie trotzdem ab: Es streamt, was passt, und **lagert auf die Platte aus**, was nicht passt. Im März 2026 ließ das DuckDB-Team alle 99 TPC-DS-Abfragen mit Skalierungsfaktor 300 auf dem [günstigsten MacBook](https://duckdb.org/2026/03/11/big-data-on-the-cheapest-macbook.html) mit 8 GB RAM laufen: fertig in 79 Minuten.

> [!NOTE]
> Zum Nachmachen: Lade die drei Dateien `yellow_tripdata_2025-0{1,2,3}.parquet` und `taxi_zone_lookup.csv` von der NYC-TLC-Website und führe die drei Abfragen oben in jeder Engine aus. Die SQLite-Datei wurde mit DuckDBs eigener `sqlite`-Erweiterung erzeugt (`ATTACH 'taxi.sqlite' (TYPE sqlite)`). Einzelmessungen auf einer Maschine sind ein Plausibilitätscheck, keine Rangliste.

## DuckDB vs. SQLite, Polars, pandas, ClickHouse, Spark und BigQuery

Die meisten „DuckDB vs. X“-Fragen sind eigentlich die Frage: Welche Art von Problem liegt vor? Hier die ganze Familie auf einer Seite:

| | **DuckDB** | **SQLite** | **Polars** | **pandas** | **ClickHouse** | **Spark** | **BigQuery / Snowflake** |
|---|---|---|---|---|---|---|---|
| **Was es ist** | Eingebettete Analyse-SQL-DB | Eingebettete Transaktions-SQL-DB | DataFrame-Bibliothek (Rust) | DataFrame-Bibliothek | Spaltenorientierter DB-Server | Verteilte Compute-Engine | Verwaltetes Cloud-Warehouse |
| **Läuft als** | Bibliothek im Prozess | Bibliothek im Prozess | Bibliothek im Prozess | Bibliothek im Prozess | Server oder Cluster | Cluster | Cloud-Dienst |
| **Stark bei** | SQL-Analysen auf Dateien und DataFrames | Vielen kleinen Lese- und Schreibzugriffen | DataFrame-Pipelines | Kleinen Daten, großem Ökosystem | Echtzeit-Analysen, vielen Nutzern | ETL im Terabyte-Bereich | Gemeinsamen, kontrollierten Analysen in jeder Größe |
| **Schwach bei** | Vielen gleichzeitigen Schreibern | Scans und Aggregationen | SQL-orientierten Teams | Speicher, Tempo bei Größe | Einbettung, Betriebsaufwand | Kleinen Daten (Overhead) | Latenz, Kosten häufiger Scans |
| **Daten größer als RAM** | Ja, lagert auf Disk aus | Ja (zeilenweise) | Ja, Streaming-Engine | Nein | Ja | Ja | Ja |
| **Wählen, wenn** | Eine Person oder ein Job, MB bis Hunderte GB | Die eigenen Daten einer App | Du in DataFrames denkst | Daten locker in den RAM passen | Dashboards für Hunderte Nutzer | Daten nicht auf eine große Maschine passen | Eine Firma eine gemeinsame Wahrheit teilt |

Drei Unterscheidungen erledigen den Großteil:

- **DuckDB vs. SQLite** ist OLAP vs. OLTP. Behalte SQLite (oder PostgreSQL) für den Zustand deiner Anwendung, nimm DuckDB, um ihn zu analysieren. DuckDB kann die SQLite-Datei sogar per `ATTACH` einbinden und direkt abfragen.
- **DuckDB vs. Polars** ist vor allem SQL vs. DataFrame-API. Beide sind schnell, beide streamen, und sie tauschen Daten über Arrow ohne Kopien aus. Nimm das, was dein Team leichter liest.
- **DuckDB vs. ClickHouse** ist eingebettet vs. Server. ClickHouse bedient aus einem Cluster Hunderte gleichzeitige Dashboard-Nutzer; DuckDB sitzt in einem einzigen Programm.

## Wo DuckDB das Warehouse schlägt und wo nicht

Der nützlichste Rahmen für DuckDB ist nicht „statt BigQuery“, sondern **„vor und neben BigQuery“**.

DuckDB gewinnt, wenn:

- **eine Person oder ein Job** die Fragen stellt: eine Analystin im Notebook, ein nächtlicher Batch-Job, ein CI-Test.
- **die Daten eine Datei oder ein Extrakt sind**: Parquet auf S3 oder GCS, ein CSV-Export, ein Ausschnitt des Warehouse.
- **Latenz wichtiger ist als Skalierung**: 40 ms in einer Notebook-Schleife schlagen jeden Zwei-Sekunden-Roundtrip zu einem Cloud-Dienst.
- **du Tests für Datencode willst.** Ein dbt-Projekt oder eine SQL-Transformation läuft in der CI in Sekunden gegen eine DuckDB-Datei, ohne Cloud-Zugangsdaten. dbt v2 (September 2026) [bringt den DuckDB-Adapter direkt mit](https://duckdb.org/2026/09/22/dbt-fusion.html).

Das Warehouse gewinnt weiterhin, wenn:

- **viele Menschen und Dienste** gleichzeitig dieselben Daten brauchen, mit Rollen, Audit-Logs, Row-Level-Security und Freigaben.
- **die Daten viele Terabyte erreichen** oder Abfragen regelmäßig mehr scannen, als eine große Maschine schnell lesen kann.
- **du verwalteten Betrieb brauchst**: Backups, Hochverfügbarkeit, Governance und jemand anderes in Rufbereitschaft.

Und das Kostenargument ist subtiler, als der Hype nahelegt. Die fünf oben genutzten Spalten ergeben für 11,2 Millionen Zeilen weniger als ein halbes Gigabyte. In BigQuery On-Demand kostet eine Abfrage über alle fünf bei [6,25 $ pro gescanntem TiB](https://cloud.google.com/bigquery/pricing), nach dem kostenlosen ersten TiB pro Monat, etwa einen Viertelcent. **Bei dieser Größe spart DuckDB kein Geld, sondern den Roundtrip.** Das Kostenargument beginnt, wenn Dashboards und geplante Jobs den ganzen Tag Terabytes neu scannen. Dann kann ein stabiler Extrakt als Parquet, abgefragt mit DuckDB, eine echte Zeile von der Rechnung streichen. Wenn du noch beim Warehouse selbst schwankst, lies [BigQuery vs. Snowflake: Ein ehrlicher Vergleich](https://www.alekseialeinikov.com/de/blog/topics/data/bigquery-vs-snowflake-2026-ehrlicher-vergleich).

> [!KEY]
> DuckDB ersetzt nicht das Warehouse. Es ersetzt den Cluster, den du gerade für Daten bauen wolltest, die auf eine Maschine passen, und die hundert kleinen Abfragen, die du nur zum Anschauen in die Cloud geschickt hast.

![Wo DuckDB passt: pandas und Polars für Daten im RAM, DuckDB für einen Prozess von Megabytes bis Hunderte Gigabyte, DuckDB mit Quack, DuckLake oder MotherDuck für gemeinsamen Zugriff, und BigQuery, Snowflake oder ClickHouse für viele Nutzer im Terabyte-Bereich.](https://www.alekseialeinikov.com/blog/duckdb-where-it-fits.webp "Die echte Grenze ist nicht die Datenmenge, sondern wie viele Schreiber und Leser die Daten teilen.")

## Die echte Grenze ist Nebenläufigkeit, nicht Größe

Die meisten erwarten, dass DuckDB an der Datenmenge scheitert. In der Praxis ist die Grenze: **Wer schreibt sonst noch?**

Im reinen In-Process-Modus kann [ein Prozess eine Datenbankdatei lesend und schreibend öffnen](https://duckdb.org/docs/current/connect/concurrency.html), mit beliebig vielen Threads, oder viele Prozesse öffnen sie nur lesend. Zwei Dienste können nicht gleichzeitig in dieselbe `.duckdb`-Datei schreiben. Das ist ein bewusster Kompromiss: Den Zustand im Speicher eines Prozesses zu halten, ist ein Grund für das Tempo.

Zwei Entwicklungen aus 2026 verschieben diese Grenze:

- **Quack, DuckDBs eigenes Client-Server-Protokoll.** Seit Mai 2026 als Vorschau verfügbar, lässt es jeden DuckDB-Prozess seine Datenbanken per HTTP bereitstellen, und jede andere DuckDB bindet sie per `ATTACH` ein. In den [Benchmarks des Teams](https://duckdb.org/2026/05/12/quack-remote-protocol.html) übertrug Quack 60 Millionen Zeilen in 4,9 Sekunden, das PostgreSQL-Protokoll brauchte 158, und schaffte mit acht Threads rund 5.400 kleine Schreibtransaktionen pro Sekunde, mehr als PostgreSQL auf denselben Maschinen. Mit DuckDB 2.0 wird Quack stabil.
- **DuckLake, ein Lakehouse-Format auf SQL-Basis.** Die Daten liegen als Parquet im Objektspeicher; der Katalog (welche Dateien welche Tabellenversion bilden) liegt in einer echten Datenbank wie PostgreSQL. Viele DuckDB-Instanzen können dann gleichzeitig dieselben Tabellen lesen und schreiben. DuckLake 1.0 wurde im April 2026 für produktionsreif erklärt. Es löst dasselbe Problem wie Iceberg und Delta, mit einem einfacheren Katalog; die Abwägung zwischen diesen beiden steht in [Iceberg vs. Delta Lake: Ein verständlicher Leitfaden](https://www.alekseialeinikov.com/de/blog/topics/data/iceberg-vs-delta-lake-2026-vergleich).

Wer nichts davon selbst betreiben will, nimmt **MotherDuck**: DuckDB in der Cloud mit Speicher, Rechenleistung pro Nutzer, Freigaben und Zugriffskontrolle. Die [Preise](https://motherduck.com/product/pricing/) umfassen einen kostenlosen Lite-Plan (10 GB Speicher, 10 Stunden Rechenzeit pro Monat) und einen Business-Plan für 250 $ pro Organisation und Monat plus Nutzung. Die EU-Regionen Frankfurt und Dublin sind für DSGVO-bewusste Teams in Deutschland ein wichtiger Punkt.

## Was neu ist in DuckDB 2.0

DuckDB 2.0 mit dem Codenamen „Cyanoptera“ steht im [Release-Kalender](https://duckdb.org/release_calendar.html) für den 21. Oktober 2026, ein Bugfix-Release 2.0.1 ist für November geplant. Die [Vorschau](https://duckdb.org/2026/08/17/duckdb-20-highlights.html) nennt über 10.000 Commits seit Version 1.5. Die Neuerungen, die die Nutzung verändern:

- **DuckDB als Server.** Quack wird stabil, und die neue Anweisung `CONNECT` richtet deine Sitzung auf eine entfernte DuckDB oder auf PostgreSQL bzw. MySQL aus und schiebt das SQL dorthin, wo es ausgeführt wird.
- **`VARIANT` als vollwertiger Typ.** Semistrukturierte Daten (etwa JSON-Logs) werden automatisch in Spalten zerlegt. Sie komprimieren und lassen sich abfragen wie typisierte Daten, ohne dass du ein Schema deklarierst.
- **Trigger**, `BEFORE` und `AFTER`, pro Zeile oder pro Anweisung: Audit-Tabellen ohne Anwendungscode.
- **Asynchrones I/O** in der ganzen Engine, mit den größten Gewinnen auf S3 und anderem Netzwerkspeicher.
- **`NEAREST`-Joins** für Top-k-Ähnlichkeitssuche über Embeddings, nützlich, wenn du abwägst, ob du überhaupt [eine eigene Vektordatenbank brauchst](https://www.alekseialeinikov.com/de/blog/topics/data/brauchst-du-eine-vektordatenbank-postgres-vs-dedizierte-2026).
- **Ein neues Speicherformat und ein neuer PEG-basierter SQL-Parser**, dazu wenige Breaking Changes. Von 2.0 geschriebene Dateien nutzen standardmäßig das neue Format; pinne also Versionen, bevor du gemeinsam genutzte Dateien aktualisierst.

Wenn dir Stabilität wichtiger ist als Features: Die Linie 1.4 ist das Long-Term-Support-Release mit Support bis November 2026; ab 1.4 ist jede zweite Minor-Version LTS.

## Ein praktischer Einstieg

Du brauchst keinen Migrationsplan, um von DuckDB zu profitieren. Fang klein an:

1. **Ersetze den langsamsten pandas-Schritt** in einem Notebook durch `duckdb.sql(...)` auf demselben DataFrame oder derselben Parquet-Datei und lass den Rest, wie er ist.
2. **Exportiere eine stabile Warehouse-Tabelle** einmal täglich als Parquet und richte explorative Arbeit auf die Datei statt aufs Warehouse.
3. **Lass deine SQL-Transformationen in der CI gegen DuckDB laufen**, damit ein kaputtes Modell im Pull Request scheitert und nicht in Produktion.
4. **Erst dann** entscheide, ob du gemeinsamen Zugriff über MotherDuck, Quack oder DuckLake brauchst oder ob das Warehouse einfach die gemeinsame Wahrheit bleibt.

Behalte das Modell im Kopf: **ein Prozess, spaltenorientiert, vektorisiert, liest Dateien dort, wo sie liegen.** Alles, worin DuckDB glänzt, folgt daraus, und ebenso alles, wofür es nicht gebaut ist. Wenn du es zuerst in die großen Datenbankfamilien einordnen willst, beginne mit [SQL vs. NoSQL: Datenbanktypen richtig wählen](https://www.alekseialeinikov.com/de/blog/topics/data/sql-vs-nosql-2026-datenbanktypen-acid-base-richtig-waehlen).

## Fazit

DuckDB verdient seinen Hype bei einem engen, aber sehr häufigen Problem: Eine Person oder ein Job stellt analytische Fragen an Daten, die auf eine Maschine passen. Dort ist es schneller als pandas, weit schneller als SQLite, bei den meisten Aufgaben mindestens so schnell wie Polars, und es braucht keinerlei Infrastruktur. Es ist kein gemeinsames Warehouse, und wer das ignoriert, landet bei Dateisperren-Fehlern. Nutze es vor und neben BigQuery oder Snowflake, nicht statt ihnen, und behalte die Nebenläufigkeit im Blick: Mit Quack und DuckLake verschiebt sich die Grenze zwischen „Laptop-Datenbank“ und „richtiger Datenbank“ schneller als jeder andere Teil des Datenstacks.