DuckDB: embedded columnar OLAP-Datenbank für lokale Datenanalyse

Was ist DuckDB?

DuckDB ist eine embedded columnar OLAP-Datenbank, entwickelt seit 2018 von Mark Raasveldt und Hannes Mühleisen am CWI (Centrum Wiskunde & Informatica) in Amsterdam. Inspiriert von SQLite (single-file, no server), aber columnar statt row-orientiert -- der Vergleich "SQLite für Analytics" trifft den Kern. Im Mai 2026 ist Version 1.2 stabil mit verbesserter Apache Arrow-Integration, Vector-Search-Extension und Parquet-Compression-Optimierungen.

Lizenz: MIT, vollständig Open Source, keine Lizenz-Themen. DuckDB Labs (gegründet 2021) bietet kommerziellen Support und MotherDuck (managed DuckDB Cloud) als Hosting-Option, aber der Kern bleibt MIT-OSS ohne Open-Core-Modell.

DuckDB läuft als Library in Python, Node, R, Rust, Java, Go, C++. Eine DuckDB-Datenbank ist eine Datei (.duckdb-Endung) oder in-memory. Im Gegensatz zu ClickHouse braucht DuckDB keinen Server -- es ist eingebettet in der Anwendung, wie SQLite. Im Gegensatz zu SQLite ist es columnar und optimiert auf Analytical-Queries -- 50-100x schneller als SQLite bei Aggregaten.

DuckDB-Killer-Feature: Reading External Data Formats. Eine DuckDB-Query kann direkt auf CSV, Parquet, JSON, Arrow, Iceberg, Delta Lake-Dateien arbeiten -- lokal auf Disk oder über HTTP/S3-Pfade. SELECT * FROM 'https://example.com/data.parquet' funktioniert ohne Vorab-Import. Damit wird DuckDB zur perfekten Analyse-Schicht über bestehende Daten-Lakes oder S3-basierte Daten.

In unserem Stack nutzen wir DuckDB für ad-hoc-Analytics über Treuhand-Mandanten-Snapshots (Postgres-Export als Parquet -> DuckDB-Query), für Log-Analyse (Loki-Export als JSON -> DuckDB), und für Pandas-Replacement in Python-Skripten (100x schneller bei grösseren Daten). Im Mai 2026 ist DuckDB die de-facto-Standard-Library für lokale Daten-Analyse.

Warum es wichtig ist

DuckDB hat im Mai 2026 eine Lucke besetzt, die zwischen SQLite (zu klein/zu langsam für Analytics) und ClickHouse (zu gross/Server-basiert) klaffte. Drei Gründe, warum DuckDB im CH-KMU-Treuhand-Kontext relevant ist.

Erstens: lokale Datenanalyse ohne Server-Aufwand. Ein Treuhand-Analyst will den Buchungs-Daten-Snapshot eines Mandanten (5 GB CSV oder Parquet) analysieren -- häufige Buchungs-Konten, monatliche Trends, Anomalie-Erkennung. Mit Pandas und 5 GB Daten kämpft man mit OOM-Errors auf einem 16-GB-Laptop. Mit DuckDB in Python: SELECT-Statements über die gleichen 5 GB in Sekunden, ohne Out-of-Memory.

Zweitens: Direkter Zugriff auf Cloud-Daten ohne ETL. SELECT * FROM 's3://bucket/treuhand-export.parquet' WHERE buchungs_konto = 1000 -- DuckDB liest direkt aus S3, ohne Vorab-Import. Damit wird ein Treuhand-Datenwarehouse ohne Daten-Bewegung möglich: Daten liegen in Hetzner Storage Box als Parquet, Queries laufen lokal aus DuckDB.

Drittens: Pandas-Replacement in Python-Pipelines. Pandas ist ein Industrie-Standard, aber 1) Single-Threaded, 2) RAM-hungrig, 3) bei > 1 GB Daten oft unpraktisch. DuckDB ist Multi-Threaded, RAM-effizient (kann auf Disk spillen) und 5-50x schneller bei Standard-Analyse-Workloads. Ein Pandas-DataFrame ist 1:1 austauschbar mit einer DuckDB-Tabelle via Arrow-Format.

Für welche Fälle ist DuckDB NICHT gedacht? Als Production-DB für Web-Anwendungen (das ist Postgres-Job). Als Multi-User-Server (DuckDB ist embedded, ein File-Lock pro Schreiber). Als Cluster für riesige Daten über 100 GB (das ist ClickHouse-Territorium). DuckDB ist ein Analyse-Werkzeug, kein Operational-Store.

Im Mai 2026 ist DuckDB in vielen Data-Science-Stacks Pflicht: Apache Airflow, dbt, Dagster, Streamlit-Apps haben native DuckDB-Integration. MotherDuck (DuckDB Cloud) ist als Option für geteilte DuckDB-Datenbanken verfügbar -- relevant für Teams, die DuckDB-Workflows über mehrere Analysten teilen wollen.

Wie es funktioniert

DuckDB ist eine in C++ geschriebene Library mit Bindings für alle gängigen Sprachen. Der einfachste Use-Case in Python:

import duckdb

# In-Memory-Query auf einer CSV result = duckdb.sql(""" SELECT buchungs_konto, count() AS n, sum(betrag) AS total FROM '/data/buchungen.csv' WHERE jahr = 2025 GROUP BY buchungs_konto ORDER BY total DESC LIMIT 20 """) result.show()

# Pandas-Integration import pandas as pd df = pd.read_csv('/data/mandanten.csv') result = duckdb.sql("SELECT * FROM df WHERE branche = 'Treuhand'").fetchdf()

Die Query-Engine ist Vectorized Execution -- Operations werden auf Batches von tausenden Zeilen gleichzeitig ausgeführt, was moderne CPU-SIMD-Instruktionen optimal nutzt. Compression ist columnar-typisch effizient (10-30x bei realistischen Daten).

DuckDB unterstützt persistent Files (.duckdb) mit ACID-Transaktionen, oder in-memory. Eine .duckdb-Datei kann mehrere Tabellen, Views und Schemas enthalten. Schema-Evolution ist via ALTER TABLE möglich, aber DuckDB ist primär auf Read-Heavy-Workloads optimiert -- häufige Updates und Deletes auf grossen Tabellen sind nicht der Sweet-Spot.

External Data Access:

# Direkter Parquet-Read aus S3 (mit httpfs Extension) INSTALL httpfs; LOAD httpfs; SELECT * FROM 's3://bucket/data.parquet' LIMIT 100;

# JSON-Read mit Schema-Inferenz SELECT * FROM read_json_auto('log.jsonl');

# Iceberg-Tabellen lesen INSTALL iceberg; LOAD iceberg; SELECT * FROM iceberg_scan('s3://bucket/iceberg-table/');

Extensions im Mai 2026: httpfs (S3/HTTP), parquet, json, vss (Vector Similarity Search), spatial (Geo), iceberg (Apache Iceberg), delta (Delta Lake), postgres_scanner (live Read aus Postgres), mysql_scanner.

Multi-Threading ist standardmässig aktiv, DuckDB nutzt alle verfügbaren CPU-Cores. Auf einem 8-Core-Laptop laufen Aggregat-Queries über 10 GB Parquet typisch in 1-5 Sekunden.

MotherDuck als Cloud-Variante: DuckDB-Datenbanken werden in der Cloud gehostet, lokale Clients können Queries an die Cloud schicken und Ergebnisse lokal verarbeiten. Hybrid-Modus: ein Teil der Daten in der Cloud, ein Teil lokal. EU-Region verfügbar.

DuckDB in 5 Schritten produktiv

1. 01Use-Case validieren: ist es Analyse (read-heavy, Aggregate) oder OLTP (write-heavy)? Bei OLTP -> SQLite oder Postgres. Bei Analyse -> DuckDB.
2. 02DuckDB als Library installieren: pip install duckdb (Python), npm install @duckdb/duckdb (Node), CRAN-Paket (R). Embedded-Mode genügt für 90 Prozent der Fälle.
3. 03Daten-Pipeline: Postgres/MySQL/CSV/Parquet -> DuckDB-Tabelle. Bei wiederkehrenden Analysen einen Snapshot als .duckdb-Datei persistieren.
4. 04Queries entwickeln: SQL-Standard, Vektor-Execution macht Aggregate sehr schnell. WITH-CTEs und Window-Functions voll unterstützt. Visualisierung via Streamlit, Dash oder Jupyter.
5. 05Sharing-Strategie: bei Multi-Analysten-Teams MotherDuck prüfen (EU-Region verfügbar), oder DuckDB-Files in S3/Storage-Box mit Read-Only-Sync.

Wann DuckDB einsetzen

Die richtige Wahl, wenn (a) Datenanalyse lokal ohne Server-Aufwand laufen soll, (b) Pandas an seine Grenzen kommt (RAM, Single-Threading), oder (c) Daten in S3-Parquet, CSV oder JSON liegen und direkt abgefragt werden sollen.

Konkrete Szenarien: Treuhand-Reporting über Mandanten-Buchungs-Snapshots (Postgres-Export als Parquet, DuckDB-Query lokal), Log-Analyse aus Loki-Export, Web-Analytics-Snapshots für ad-hoc-Reports, KPI-Dashboards in Streamlit mit DuckDB als Engine, Datenqualitäts-Prüfungen über CSV-Importe, Pandas-Replacement in Python-ETL-Pipelines.

Neue 2026er-Use-Cases: dbt mit DuckDB als Compute-Engine (statt Snowflake/BigQuery für kleine Teams), Dagster/Airflow-Tasks mit DuckDB-Transformations, KI-Datenvorbereitung (Embedding-Datensätze, RAG-Source-Files in DuckDB-Tabelle plus VSS-Extension für Search).

MotherDuck (DuckDB Cloud) ist attraktiv für Teams, die DuckDB-Workflows teilen wollen: gemeinsame Daten-Layer in der Cloud, lokale Query-Performance, EU-Region. Self-Host bleibt für reine lokale Analysen Standard -- keine Cloud nötig.

Für Excel-Power-User: DuckDB ist die natürliche Nächste-Schritt-Tech. Wer in Excel 1 Million Zeilen verarbeitet und an Performance-Grenzen stösst, kann denselben Workflow in DuckDB mit 100 Millionen Zeilen weiter machen -- SQL-ähnliche Sprache, vergleichbares Mental-Modell.

Wann NICHT

Niemals als Production-DB für Web-Anwendungen mit mehreren Anwendern. DuckDB ist embedded und Single-Writer -- ein File-Lock pro Schreib-Prozess. Wer Multi-User-Anwendungen baut, gehört in Postgres oder ClickHouse.

Für hochfrequente OLTP-Workloads (häufige Einzel-INSERT-UPDATE-DELETE) ist DuckDB nicht optimiert. Schreib-Operationen sind langsamer als bei SQLite, da das columnar-Format Reorganisation bei jedem Schreib-Vorgang braucht. DuckDB ist auf Read-Heavy-Analytics gebaut.

Für wirklich grosse Daten (> 100 GB pro Datenbank) wird DuckDB unhandlich. ClickHouse mit Cluster-Setup ist hier richtig. DuckDB ist auf Single-Node-Analyse von 1-100 GB Daten optimal -- darüber hinaus lohnt ein Server-basiertes System.

Für Echtzeit-Daten-Pipelines mit kontinuierlichen Updates ist DuckDB nicht das richtige Werkzeug. DuckDB ist auf Batch-Loads optimiert -- Daten kommen einmal, werden viele Male abgefragt. Realtime-Streaming gehört in ClickHouse oder Kafka + ClickHouse.

Für Multi-User-Sharing ohne MotherDuck: lokale DuckDB-Files sind nicht netzwerk-share-fest. Wenn mehrere Analysten gleichzeitig auf eine .duckdb-Datei zugreifen sollen, braucht es MotherDuck oder eine andere Sharing-Schicht.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. DuckDB 1.2 release notes · 2026-05
2. DuckDB documentation - extensions and SQL · 2026-05
3. DuckDB MIT License · 2026-05
4. MotherDuck Cloud pricing and EU region · 2026-05