DuckDB als Speicher: Ersetzt ETL Postgres

DuckDB als kompaktes Analytics-Warehouse: ETL und Postgres überflüssig

DuckDB ermöglicht den Aufbau eines Analytics-Warehouses in einer einzigen .duckdb-Datei – ohne ETL-Pipelines und Postgres für OLAP-Workloads. Der Engine verarbeitet Parquet-, CSV- und JSON-Dateien direkt aus lokalen Speichern oder S3/GCS und sorgt für schnellen Datenzugriff bei Dashboards und Reports, ohne verteilte Infrastruktur. Ideal für ressourcenarme Teams, die Datenfrische und Reproduzierbarkeit priorisieren.

Pain Points des klassischen ETL + Postgres-Stacks

Postgres meistert OLTP-Workloads hervorragend, doch OLAP-Abfragen lösen Kaskadenprobleme aus: Indizes bremsen das Vakuumieren, Aggregates konkurrieren mit Transaktionen, ETL-Jobs verheddern sich mit Schema-Änderungen. Teams verbringen mehr Zeit mit Admin-Aufgaben als mit Analyse. DuckDB eliminiert diese Schwachstellen als eingebettete OLAP-Engine ohne persistenten Speicher.

Die Architektur vereinfacht sich zu:

• Quellen (DBs, S3, CSV) → Parquet-Snapshots → DuckDB (Bronze-/Silver-/Gold-Layer) → BI-Exports.

Der Pipeline reduziert sich auf ein geplantes Skript mit Views und Exports – minimaler Ops-Aufwand.

SLAs für ein DuckDB-Mikro-Warehouse

Klare SLAs ohne Cluster-Komplexität:

• Datenfrische: Updates alle 15–60 Minuten mit Zeitstempel-Logging.
• Genauigkeit: Metriken in versionskontrollierten SQL-Views mit Code-Review.
• Performance: p95 < 2 s für Dashboards mit 90 Tagen Daten.
• Wiederherstellung: Vollständiger Rebuild aus Parquet in <30 Minuten.
• Ops/Kosten: Eine Datei + ein Job, keine laufenden Speicherkosten.

Die .duckdb-Datei lässt sich einfach backupen und versetzen.

Anwendungsfall: Product Analytics

Für B2B-SaaS mit Events in einer relationalen DB und Logs in S3:

• Tägliche Snapshots von Tabellen in partitioniertes Parquet.
• Events als datumspartitionierte Parquet-Dateien.
• Gold-Layer-Metriken-Views (WAUs, Retention-Cohorts).
• Kuratierte Parquet-Exports für BI-Tools.

Die httpfs-Erweiterung erlaubt direkte S3-Lesezugriffe ohne lokale Kopien. DuckDB aggregiert mehrere Parquet-Dateien zu einer einzigen Tabelle.

Praktische Implementierungs-Skripte

Update-Skript (Python)

import duckdb
from datetime import datetime

DB = "micro_warehouse.duckdb"

con = duckdb.connect(DB)
con.execute("INSTALL httpfs;")
con.execute("LOAD httpfs;")

con.execute("""
CREATE OR REPLACE VIEW bronze_events AS
SELECT *
FROM read_parquet('data/events/date=*/events-*.parquet');
""")

con.execute("""
CREATE OR REPLACE VIEW silver_events AS
SELECT
  CAST(event_time AS TIMESTAMP) AS event_time,
  user_id,
  team_id,
  event_name,
  NULLIF(properties, '') AS properties
FROM bronze_events
WHERE user_id IS NOT NULL;
""")

con.execute("""
CREATE OR REPLACE VIEW gold_weekly_active_teams AS
SELECT
  date_trunc('week', event_time) AS week,
  COUNT(DISTINCT team_id) AS weekly_active_teams
FROM silver_events
GROUP BY 1
ORDER BY 1;
""")

con.execute("""
COPY (SELECT * FROM gold_weekly_active_teams)
TO 'exports/gold_weekly_active_teams.parquet' (FORMAT PARQUET);
""")

con.execute("CREATE OR REPLACE TABLE ops_refresh_log AS SELECT 1 AS dummy;")
con.execute("""
INSERT INTO ops_refresh_log
SELECT 1
""")

print("Update OK:", datetime.utcnow().isoformat(), "DB:", DB)

Dieses Skript baut Bronze-/Silver-/Gold-Layer auf und exportiert Metriken.

Inkrementelle Updates

Für Upserts MERGE auf Keys (Woche, team_id) in eine materialisierte Tabelle nutzen, gleitende Fenster neu berechnen.

Migration ohne Ausfälle

OLTP in Postgres belassen und OLAP zu DuckDB migrieren – via postgres_scanner-Erweiterung für Lese-/Schreibzugriff auf live Instanz. Abfragen schrittweise umstellen, ohne Refactoring.

Einschränkungen von DuckDB als Warehouse

Stark bei:

• Wenigen Analysten (Dashboards, Exports).
• Append-only oder Snapshot-Daten.
• Portablen Parquet-Workflows.

Nicht für:

• Hohe Konkurrenz mit interaktiven Nutzern.
• OLTP-Writes mit ACID-Garantien.
• Multi-Tenant-Row-Level-Security.
• Enterprise-Data-Verträge mit vielen Produzenten.

Kernbotschaften

• DuckDB: eingebettete OLAP-Engine für eine Datei, direkte Parquet/S3-Lesung.
• Stack vereinfacht: Skript + Views statt ETL + Postgres.
• Erreichbare SLAs: 15-Min.-Frische, p95<2 s, <30-Min.-Recovery.
• Schrittweise Migration via postgres_scanner.
• Limits: niedrige Konkurrenz, kein OLTP.

— Editorial Team