DuckDB vs SQLite: Welche Embedded-DB passt zu deinem Workflow?

Du hast Daten in CSV-Files, Parquet-Exports oder lokalen Tabellen — und brauchst SQL ohne Server. DuckDB und SQLite versprechen das beide: embedded, Zero-Config. Aber sie sind für fundamental verschiedene Workloads gebaut, und falsch wählen kostet dich Stunden.

TL;DR

SQLite ist die meist-deployte DB der Welt — optimiert für transaktionale Workloads, Embedded Apps, Row-Level-Operationen.

DuckDB ist eine analytische Engine, gebaut für column-orientierte Queries, Aggregations und Scans über große Datasets.

Sie sind keine Konkurrenten — sie lösen unterschiedliche Probleme.

• App, die individuelle Records liest/schreibt: SQLite
• Daten analysieren, Aggregations, Parquet explorieren: DuckDB

Feature-Vergleich

Wo DuckDB gewinnt: Analytische Queries

DuckDB ist purpose-built für den analytischen Workload, mit dem Data-Engineers täglich arbeiten. Columnar-Storage = Aggregations, GROUP BYs und Scans über Millionen Rows dramatisch schneller als SQLite.

-- DuckDB
SELECT
    region,
    product_category,
    DATE_TRUNC('month', order_date) AS month,
    SUM(revenue) AS total_revenue,
    COUNT(DISTINCT customer_id) AS unique_customers,
    ROUND(AVG(revenue), 2) AS avg_order_value
FROM read_parquet('sales_2025/*.parquet')
WHERE order_date >= '2025-01-01'
GROUP BY region, product_category, month
ORDER BY total_revenue DESC;

Liest direkt aus Parquet — kein ETL, kein Import, keine Schema-Definition. In SQLite müsstest du alles erst in eine Tabelle laden.

Warum schneller?

DuckDB nutzt Vectorized Execution — Batches von 2.048 Werten gleichzeitig statt Row-by-Row. Plus Columnar-Storage (nur relevante Spalten gelesen) — eine 10-Mio.-Row-Aggregation, die in SQLite 45 Sekunden braucht, läuft in DuckDB oft unter 2 Sekunden.

Wo SQLite gewinnt: Transactional + Embedded

SQLite ist nicht der Versuch, eine Analytics-Engine zu sein. Es ist die meist-deployte DB des Planeten — in jedem iPhone, Android, Browser, Tausenden Desktop-Apps. Stärke: schnelle, zuverlässige Single-Record-Operationen.

-- SQLite — klassisches Transactional-Pattern
INSERT INTO user_sessions (user_id, session_token, last_active, ip_address)
VALUES ('usr_42', 'tok_abc123', datetime('now'), '192.168.1.50')
ON CONFLICT(user_id) DO UPDATE SET
    session_token = excluded.session_token,
    last_active = excluded.last_active,
    ip_address = excluded.ip_address;

SELECT * FROM user_sessions WHERE user_id = 'usr_42';

Für diese Workloads — Single-Row Insert/Update/Lookup — ist SQLite extrem schnell. Row-Storage = ein vollständiges Record lesen ist ein sequentieller Disk-Read, DuckDB müsste aus Column-Segments rekonstruieren.

Warum SQLite Embedded-Apps dominiert

• Zero-Config: Eine Datei kopieren = DB
• Single-File-Storage: Komplette DB in einer portablen Datei
• Außergewöhnliche Reliability: Aviation-Software, Banking, OS
• Tiny Footprint: ~600 KB Library
• 24 Jahre Battle-Testing

Python-Experience Side by Side

DuckDB: DataFrame-friendly

import duckdb

con = duckdb.connect()

result = con.sql("""
    SELECT country, COUNT(*) AS event_count, AVG(magnitude) AS avg_magnitude
    FROM read_csv_auto('earthquake_data.csv')
    WHERE magnitude > 3.0
    GROUP BY country
    ORDER BY event_count DESC
    LIMIT 20
""").fetchdf()  # Pandas DataFrame direkt

import pandas as pd
df = pd.read_csv('sensors.csv')

high_readings = con.sql("""
    SELECT sensor_id, MAX(reading) as peak
    FROM df
    WHERE reading > 100
    GROUP BY sensor_id
""").fetchdf()

SQLite: Simpel und zuverlässig

import sqlite3

con = sqlite3.connect('app.db')
cur = con.cursor()

cur.execute("""
    CREATE TABLE IF NOT EXISTS events (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        event_type TEXT NOT NULL,
        payload TEXT,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
    )
""")

cur.execute(
    "INSERT INTO events (event_type, payload) VALUES (?, ?)",
    ('user_login', '{"user_id": 42}')
)
con.commit()

DuckDB ist für Analytics-Workflow (Files in, DataFrames out), SQLite für strukturiertes App-Daten-Management.

DuckDB wählen, wenn:

• Ad-hoc Data-Exploration: CSVs, Parquets, JSON, jetzt querien
• Lokale Analytics: Aggregations, Window Functions auf Tausenden bis Hundert Millionen Rows
• Pandas durch SQL-Workflows ersetzen
• Pipeline-Prototyping vor Spark oder Warehouse
• WASM-Analytics im Browser

SQLite wählen, wenn:

• App-Backends: Mobile, Desktop, IoT, CLI
• Config- und State-Storage: Settings, Caches, Sessions
• Niedrig-Volumen-Transactional: User-Records, Logs, Queues
• Maximale Portabilität: DB überall
• Production-Reliability über Analytics-Speed

Häufige Missverständnisse

"DuckDB ersetzt SQLite" — Nein. Unterschiedliche Workloads. DuckDB für Mobile-App-Local-Storage = Gabelstapler für Einkäufe.

"SQLite kann kein Big Data" — SQLite handelt große DBs gut für Transactional-Workloads. Issue ist analytische Performance, nicht Capacity.

"DuckDB zu neu für Production" — v1.0 im Juni 2024, seit 0.8+ stabil. Wird produktiv in vielen Firmen genutzt. SQLites 24-Jahre-Record bleibt aber schwer zu schlagen.

"Nimm einfach Postgres" — Wenn du Server-DB brauchst, klar. Aber DuckDB und SQLite glänzen, weil embedded.

Beide nutzen

Absolut — viele Teams tun es. Praktisches Pattern:

1. SQLite managt App-Transactional (User-Records, Configs, Job-Metadata)
2. DuckDB macht analytische Queries auf exportierten Daten, Logs, Parquet-Snapshots
3. DuckDB kann SQLite direkt attachen:

INSTALL sqlite;
LOAD sqlite;
ATTACH 'app.db' AS app_data (TYPE SQLITE);

SELECT event_type, COUNT(*) AS occurrences,
       DATE_TRUNC('hour', created_at) AS hour
FROM app_data.events
GROUP BY event_type, hour
ORDER BY occurrences DESC;

SQLite-Reliability fürs Schreiben, DuckDB-Speed fürs Lesen.

Im Browser: WASM für beide

Beide unterstützen WebAssembly, aber unterschiedlich. Für browser-basierte Daten-Exploration — Uploaded CSVs, Parquet-Aggregations, Natural-Language-Fragen — passt DuckDB-WASM. Harbinger Explorer nutzt genau das: DuckDB-WASM läuft analytisches SQL direkt im Browser-Tab, ohne Server-Roundtrip.

FAQ

Welche ist DSGVO-konformer? Beide. Wo Daten liegen entscheidest du.

Konkurrenz zu Postgres? Nein. Postgres ist Server-DB, DuckDB/SQLite sind embedded. Ergänzen sich.

Wie groß werden DBs typisch? SQLite oft GB-Bereich, DuckDB problemlos Hundert-GB-Bereich.

Was, wenn ich beides brauche? SQLite für State, DuckDB für Analytics auf demselben File via ATTACH.

Stand: 14. Mai 2026.