Data Lake vs Warehouse vs Lakehouse: Was passt zu deinem Stack?

Die meisten Architekturdebatten kollabieren in dieselben drei Optionen: Data Lake, Data Warehouse oder Data Lakehouse. Jedes Lager hat Evangelist:innen, die sagen, ihre Wahl sei offensichtlich richtig. Realität: Jede löst ein anderes Problem — und falsch wählen kostet dich 12 Monate Migration.

TL;DR

Data Lake — Das Roh-Archiv

Speichert Daten im Native-Format — JSON, Parquet, CSV, Avro, Images, Audio — in günstigem Object Storage. Kein Schema-Enforcement beim Write.

Versprechen: Alles speichern, später entscheiden, was du brauchst.

Realität: Die meisten Lakes werden binnen 18 Monaten zu "Data Swamps":

• Dateien, an deren Erstellung sich niemand erinnert
• Mehrere Versionen desselben Datasets mit leicht anderen Schemas
• Kein durchsuchbarer Catalog → Analyst:innen finden nichts
• Roh-JSON, das niemand parsen will

import duckdb

result = duckdb.sql('''
    SELECT
        json_extract_string(raw, '$.user_id') AS user_id,
        json_extract_string(raw, '$.event_type') AS event_type,
        CAST(json_extract_string(raw, '$.ts') AS TIMESTAMP) AS event_ts
    FROM read_json_auto('s3://my-lake/events/2024/01/**.json')
    WHERE json_extract_string(raw, '$.event_type') = 'purchase'
''')

Passt für: ML-Feature-Stores, Roh-Event-Archive, Teams mit starker Data-Engineering-Disziplin, Mix aus strukturierten und unstrukturierten Workloads.

Vermeiden: Deine Primary-Consumer:innen sind SQL-Analyst:innen. Sie werden leiden.

Data Warehouse — Der SQL-First-Workhorse

Strukturierte, modellierte Daten in proprietärem Columnar-Format. Schema beim Write erzwungen. Alles getypt, indexiert, SQL-optimiert.

Major-Player: Snowflake, BigQuery, Redshift, Databricks SQL Warehouse, Azure Synapse.

Versprechen: Schnelles SQL, gute Governance, reife Tools, Analyst:innen produktiv ab Tag 1.

Realität: Du zahlst Premium für Convenience. Proprietäre Storage-Formate locken dich ein. Semi-strukturierte Daten (JSON, Nested Arrays) gehen, sind aber schmerzhaft. Python-ML auf den Daten verlangt Export.

-- Snowflake SQL
CREATE OR REPLACE TABLE orders (
    order_id     STRING NOT NULL,
    customer_id  STRING NOT NULL,
    order_total  DECIMAL(10,2),
    placed_at    TIMESTAMP_NTZ,
    status       VARCHAR(50)
);

SELECT customer_id, COUNT(*) AS order_count, SUM(order_total) AS total_spend
FROM orders
WHERE placed_at >= DATEADD(day, -30, CURRENT_TIMESTAMP())
GROUP BY 1 ORDER BY 3 DESC;

Passt für: BI-First-Teams, reife Analytics-Organisationen, regulierte Branchen, vorhersehbare SLAs.

Vermeiden: ML auf denselben Daten ohne Export. Oder Daten enthalten Roh-Files (Images, Logs, Audio), die nicht in tabellarisches Storage passen.

Data Lakehouse — Der Versuch, beides zu haben

Offene Tableformat-Standards (Delta Lake, Apache Iceberg, Apache Hudi) auf Object Storage. Du kriegst Kosten und Flexibilität eines Lakes mit SQL-Semantik, ACID, Schema-Enforcement.

Object Storage (S3/GCS/ADLS)
        │
  ┌─────┴──────────────────────┐
  │  Open Table Format         │
  │  (Delta / Iceberg / Hudi)  │
  │  – ACID Transactions       │
  │  – Schema Enforcement      │
  │  – Time Travel             │
  │  – Partition Pruning       │
  └────────────┬───────────────┘
               │
      ┌────────┴────────┐
      │                 │
  SQL Engine        ML/Python
  (Spark/Trino/     (PySpark,
   Athena/DuckDB)    MLflow)

Versprechen: Ein Storage-Layer, mehrere Compute-Engines, kein Vendor-Lockin auf Storage, SQL + Python aus derselben Tabelle.

Realität: Komplexität ist nicht trivial. Du musst Compaction, Vacuuming und File-Management selbst managen — ein Warehouse erledigt das automatisch.

from pyspark.sql import SparkSession
from pyspark.sql.types import StructType, StructField, StringType, DecimalType, TimestampType

spark = SparkSession.builder \
    .config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
    .getOrCreate()

schema = StructType([
    StructField("order_id", StringType(), False),
    StructField("customer_id", StringType(), False),
    StructField("order_total", DecimalType(10, 2), True),
    StructField("placed_at", TimestampType(), True),
])

df = spark.read.schema(schema).parquet("s3://raw/orders/")
df.write.format("delta").mode("append").option("mergeSchema", "false") \
    .save("s3://lakehouse/gold/orders/")

Passt für: Teams, die offene Standards wollen, ML + BI auf denselben Daten, Databricks/Spark-Umgebungen.

Vermeiden: Reines SQL-Team ohne Appetit auf Distributed-Compute-Management. Managed Warehouse ist produktiver.

Entscheidungsbaum

Strukturierte Daten only (Tables, keine Roh-Files)?
  ├─ JA → Brauchst du ML/Python auf denselben Daten?
  │           ├─ JA → Lakehouse
  │           └─ NEIN → Data Warehouse
  └─ NEIN → Starke Data-Engineering-Disziplin?
              ├─ JA → Lakehouse (offene Formate auf Object Storage)
              └─ NEIN → Start mit Warehouse, Lake später dazu

Zusätzliche Signale:

Trade-Offs ehrlich

Data Lake

• Günstigstes Storage, jeder Datentyp, kein Schema-Lockin

• Governance schwer, SQL-Perf ohne Engine schlecht, Swamp-Risiko real

Data Warehouse

• Beste SQL-Perf, einfachste Governance, Analyst:innen sofort produktiv

• Proprietär = Vendor-Lockin, ML braucht Export, höchste Kosten skaliert

Data Lakehouse

• Offene Formate, SQL + Python aus einer Schicht, ACID + Time Travel ohne Warehouse

• Mehr Ops-Komplexität, Engine-Wahl als zusätzliche Entscheidung, Governance weniger reif

Hybride Realität

Die meisten Firmen über 50 Engineer:innen enden hybrid. Typischer Stack:

1. Raw Zone (Data Lake): S3 mit Roh-Events, Logs, externe API-Dumps
2. Curated Zone (Lakehouse): Delta/Iceberg mit Transformation, ACID
3. Serving Zone (Warehouse oder Lakehouse): dbt-modellierte Marts, BI-Tools über Snowflake oder Databricks SQL

Das ist die Medaillon-Architektur — Bronze (Raw Lake), Silver (Lakehouse), Gold (Warehouse).

FAQ

Was ist die DACH-Empfehlung? eu-central-1 (AWS) oder Azure West Europe für Compliance. Snowflake hat EU-Region. Databricks läuft auf allen Hyperscalern in EU.

Iceberg oder Delta? Delta wenn Databricks gesetzt. Iceberg wenn Multi-Engine (Spark + Trino + Flink) und keine Single-Vendor-Bindung.

Reicht für ein DACH-Mittelstand-KMU ein Warehouse? Meist ja. Lakehouse-Komplexität rechtfertigt sich erst bei nennenswertem ML- oder Streaming-Workload.

Kann ich später migrieren? Lake → Warehouse: schmerzhaft, aber machbar. Warehouse → Lakehouse: extrem schmerzhaft. Offene Formate machen es leichter.

Stand: 14. Mai 2026.