Medallion vs Data Vault vs Star Schema: Entscheidungs-Framework

Deine Data-Plattform läuft auf drei Abstraktions-Layern: Ingestion, Integration und Präsentation. Die wahre Frage ist nicht, welcher Modellierungs-Ansatz "der beste" ist — sondern welche Kombination zu deiner Architektur passt. Medallion, Data Vault und Star Schema sind keine Konkurrenten. Sie lösen verschiedene Probleme auf verschiedenen Layern, und die Teams, die das verstehen, bauen Plattformen, die tatsächlich skalieren.

TL;DR für viel beschäftigte Architekten

Die Pointe: Die meisten Production-Lakehouse-Plattformen 2026 nutzen einen Hybrid — Medallion als Pipeline-Container, Data-Vault-Prinzipien in Silver für Integration und Star Schema in Gold für Konsum. Die Frage ist, ob dein Use-Case die Komplexität aller drei rechtfertigt.

Medallion Architecture: der Pipeline-Container

Medallion Architecture, popularisiert von Databricks, organisiert Daten in drei progressive Qualitäts-Layer:

• Bronze — Raw-Ingestion. Append-only, Schema-on-read, Full-Fidelity-Kopie
• Silver — Bereinigt, dedupliziert, conformed. Business-Keys aufgelöst, Datentypen erzwungen
• Gold — Aggregiert, business-ready. Optimiert für spezifische Konsum-Patterns (Dashboards, ML-Features, APIs)

Was Medallion ist — und nicht

Medallion ist ein Daten-Processing-Pattern, keine Modellierungs-Methodologie. Es sagt dir wo Daten in ihrem Lebenszyklus leben, aber nichts darüber wie zu strukturieren. Du kannst flache CSVs in Bronze packen, Data-Vault-Modelle in Silver und Star Schemas in Gold. Oder du packst wide denormalisierte Tabellen überall. Medallion ist das egal.

Das ist gleichzeitig seine größte Stärke und häufigste Verwirrungs-Quelle. Teams adoptieren Medallion und denken, sie hätten "einen Modellierungs-Ansatz gewählt" — dabei haben sie eine Pipeline-Organisations-Strategie gewählt.

Wann Medallion allein reicht

Für kleine bis mittlere Plattformen mit weniger als 20 Source-Systemen und einem Analytics-Team funktioniert pures Medallion mit einfachen bereinigten Tabellen in Silver und aggregierten in Gold gut. Der Overhead formaler Modellierungs-Methodologien ist nicht gerechtfertigt, wenn dein Daten-Estate in einen Kopf passt.

Entscheidungs-Signal: Wenn dein Silver-Layer nur "bereinigtes Bronze" ist und dein Gold-Layer nur "gruppiertes Silver", brauchst du wahrscheinlich kein Data Vault oder formale dimensionale Modellierung.

Data Vault 2.0: die Integrations-Engine

Data Vault ist eine Modellierungs-Methodologie für den Integrations-Layer. Sie zerlegt Daten in drei Entitäts-Typen:

• Hubs — Business-Keys (z. B. customer_id, order_number). Eine Zeile pro Business-Entität.
• Links — Beziehungen zwischen Hubs (z. B. customer_placed_order). Many-to-Many per Design.
• Satellites — Beschreibende Attribute, an Hubs oder Links angehängt, mit voller History via Load-Timestamps.

Warum Data Vault existiert

Data Vault löst ein spezifisches Problem: Daten aus vielen Source-Systemen integrieren bei vollständiger History-Bewahrung und paralleler Entwicklung. Bei 50+ Source-Systemen, jedes mit eigener Definition von "Customer", gibt Data Vault dir einen strukturierten Weg, um:

1. Quellen unabhängig zu laden (paralleles ETL, keine Cross-Dependencies)
2. Jede Änderung mit Timestamps zu tracken (volle Auditierbarkeit)
3. Neue Quellen ohne Restrukturierung bestehender Modelle hinzuzufügen
4. Spät eintreffende Daten und Korrekturen zu handhaben

Die echten Kosten von Data Vault

Data Vault ist verbose. Ein einzelnes Business-Konzept wie "Kunde bestellt" — in Star Schema eine oder zwei Tabellen — wird in Data Vault zu fünf oder mehr Tabellen (Hub_Customer, Hub_Order, Link_Customer_Order, Sat_Customer_Details, Sat_Order_Details).

graph LR
    subgraph Data Vault Model
        H1[Hub: Customer]:::blue
        H2[Hub: Order]:::blue
        L1[Link: Customer_Order]:::amber
        S1[Sat: Customer_Details]:::green
        S2[Sat: Order_Details]:::green
        S3[Sat: Customer_Order_Eff]:::green
    end

    H1 --- L1
    H2 --- L1
    H1 --- S1
    H2 --- S2
    L1 --- S3

    classDef blue fill:#F0F4FF,stroke:#1e3a8a,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef green fill:#F0FFF4,stroke:#14532d,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef amber fill:#FFFBEB,stroke:#92400e,stroke-width:2px,color:#1e1e2e,font-weight:bold

① Hubs (blau) speichern nur Business-Keys — sie ändern sich nie nach Anlage ② Links (amber) fangen Beziehungen ein — auch insert-only, ermöglicht volle Beziehungs-History ③ Satellites (grün) halten alle beschreibenden Daten mit temporaler Versionierung

Diese Verbosity ist der Trade-off für Auditierbarkeit und Flexibilität. Teams, die Data Vault ohne Bedarf an diesen Properties adoptieren, zahlen den Komplexitätspreis ohne den Vorteil.

Wann Data Vault es wert ist

• Regulierte Branchen (Finance, Healthcare, Pharma), wo volle Audit-Trails non-negotiable sind
• Viele Source-Systeme (30+) mit überlappenden Business-Konzepten
• Häufig wechselnde Source-Schemas, wo rigide Modelle brechen
• Mehrere Entwicklungsteams, die parallel an verschiedenen Quellen arbeiten ohne Merge-Konflikte
• Compliance-Anforderungen für Data-Lineage und Point-in-time-Rekonstruktion

Wann Data Vault Overkill ist

• Single-Cloud-Analytics-Plattformen mit weniger als 10 Quellen
• Startups, wo Delivery-Speed wichtiger als Audit-Compliance ist
• Teams ohne dedizierte Daten-Modellierer
• Use-Cases, wo nie jemand fragt "Wie sah dieser Record am 15. März aus?"

Star Schema: der Analytics-Beschleuniger

Star Schema (und sein normalisierter Cousin Snowflake Schema) ist seit Ralph Kimballs Original-Arbeit in den 1990ern Standard für analytische Modellierung. Es strukturiert Daten in:

• Fact-Tabellen — Messbare Events (Orders, Klicks, Transaktionen). Enthält Foreign-Keys und Metriken.
• Dimension-Tabellen — Beschreibender Kontext (Customers, Products, Dates). Enthält Attribute für Filtering und Gruppierung.

Warum Star Schema den Gold-Layer dominiert

Trotz 30+ Jahre alt bleibt Star Schema die effizienteste Struktur für BI-Query-Patterns. Die Gründe sind praktisch:

1. Query-Engines optimieren dafür. Spaltenbasierte Engines (Databricks SQL, BigQuery, Redshift, Snowflake) optimieren alle Join-Patterns typisch für Star-Schema-Queries.
2. BI-Tools erwarten es. Power BI, Tableau, Looker generieren optimales SQL gegen Star-Schema-Strukturen.
3. Analysten verstehen es. Das Mental-Modell "Events umgeben von Kontext" mappt direkt auf Business-Fragen.
4. Performance ist vorhersagbar. Fact-Tabellen-Scans mit Dimension-Lookups haben gut verstandene Performance-Charakteristiken.

Star-Schema-Limitierungen

• Schema-Rigidität. Ein neues Attribut zu einer Dimension hinzuzufügen braucht DDL-Änderungen und potenziell Backfilling.
• History-Handling ist drangeschraubt. Slowly Changing Dimensions (SCD Type 2) fügen Komplexität hinzu, für die Star Schema ursprünglich nicht designt wurde.
• Schlechte Passung für Integration. Star Schema nimmt an, dass Daten schon clean und conformed sind — es ist ein Präsentations-Modell, kein Integrations-Modell.

Das Hybrid-Pattern: Medallion + Data Vault + Star Schema

Die reifsten Daten-Plattformen 2026 nutzen alle drei Ansätze auf ihrem passenden Layer. Das ist nicht Komplexität um der Komplexität willen — es platziert jede Methodologie da, wo sie am meisten Wert hinzufügt.

graph TD
    subgraph Bronze Layer
        B1[Raw Source A]:::default
        B2[Raw Source B]:::default
        B3[Raw Source C]:::default
    end

    subgraph Silver Layer - Data Vault
        HUB[Hubs: Business Keys]:::blue
        LNK[Links: Relationships]:::amber
        SAT[Satellites: Attributes + History]:::green
    end

    subgraph Gold Layer - Star Schema
        FACT[Fact Tables]:::purple
        DIM[Dimension Tables]:::rose
    end

    B1 --> HUB
    B2 --> HUB
    B3 --> HUB
    HUB --> LNK
    LNK --> SAT
    SAT --> FACT
    HUB --> DIM
    SAT --> DIM

    classDef blue fill:#F0F4FF,stroke:#1e3a8a,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef green fill:#F0FFF4,stroke:#14532d,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef amber fill:#FFFBEB,stroke:#92400e,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef rose fill:#FFF0F0,stroke:#7f1d1d,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef purple fill:#FAF0FF,stroke:#4c1d95,stroke-width:2px,color:#1e1e2e,font-weight:bold
    classDef default fill:#FAFAF8,stroke:#1e1e2e,stroke-width:2px,color:#1e1e2e

① Bronze empfängt Rohdaten aus allen Quellen — append-only, volle Fidelity ② Silver nutzt Data Vault, um zu integrieren, dedupliziert und Quellen-übergreifend zu historisieren ③ Gold materialisiert Star Schemas optimiert für spezifische Analytics-Use-Cases

Wie die Layer interagieren

Wann der volle Hybrid gerechtfertigt ist

Der volle Drei-Layer-Hybrid ist angemessen, wenn:

• Du 15+ heterogene Source-Systeme hast, die eine geteilte Daten-Plattform speisen
• Mehrere konsumierende Teams verschiedene Sichten auf dieselben Daten brauchen (Finance, Operations, Marketing)
• Regulatorische Compliance Point-in-time-Datenrekonstruktion verlangt
• Source-Schemas sich häufig ändern (SaaS-APIs, Third-Party-Feeds)
• Du dedizierte Daten-Engineering-Kapazität hast, um die Modellierungs-Layer zu warten

Wann die Mitte überspringen

Wenn deine Plattform hauptsächlich ein Analytics-Team aus weniger als 10 gut strukturierten Quellen bedient, überspring Data Vault in Silver. Nutze Medallion mit clean/conformed Tabellen in Silver und Star Schema in Gold. Das deckt 70 % der Mid-Market-Daten-Plattformen ab.

Entscheidungs-Framework

Schritt 1: Zähle deine Quellen und Teams

Schritt 2: Compliance-Anforderungen bewerten

Wenn du "Wie sahen die Daten am Datum X aus?" mit Sicherheit beantworten musst, brauchst du entweder:

• Data Vault mit Satellite-History-Tracking (strukturierter Ansatz)
• Delta Lake / Iceberg Time Travel (Infrastruktur-Ansatz)

Für die meisten Teams 2026 liefert Table-Format-Time-Travel (Delta Lakes VERSION AS OF, Iceberg Snapshot-Queries) ausreichende Point-in-time-Fähigkeit ohne den vollen Data-Vault-Overhead.

Schritt 3: Team-Skills evaluieren

Das ist der Faktor, den die meisten Architektur-Diagramme ignorieren. Data Vault braucht Modellierungs-Expertise, die viele Teams nicht haben.

Schritt 4: Deine Cloud-Plattform berücksichtigen

• Databricks — Starker Medallion-Support via Delta Live Tables. Data Vault funktioniert gut mit Unity-Catalog-Lineage-Tracking. Star Schema profitiert von Photon-Engine-Optimierungen.
• Snowflake — Dynamic Tables können Star-Schema-Materialisierung automatisieren.
• BigQuery — Materialized Views handhaben Gold-Layer-Aggregation nativ. Nested/repeated Fields können Data-Vault-Join-Komplexität in Silver reduzieren.
• Microsoft Fabric — Medallion ist First-Class-Konzept. OneLake-Shortcuts vereinfachen Bronze-Ingestion.

Häufige Anti-Patterns

Anti-Pattern 1: Data Vault überall

Hub-Link-Satellite-Strukturen im Gold-Layer zwingen Analysten zu komplexen Multi-Join-Queries für einfache Fragen. Data Vault ist eine Integrations-Methodologie — behalte sie in Silver.

Anti-Pattern 2: Medallion ohne Modellierung

Tabellen als "Bronze", "Silver", "Gold" zu labeln ohne Modellierungs-Disziplin bedeutet, dein Gold-Layer ist nur "weniger chaotisches Bronze".

Anti-Pattern 3: Star Schema als Integrations-Layer

Star Schemas direkt aus Rohdaten zu bauen, heißt: jede Source-Änderung verlangt Restrukturierung deines dimensionalen Modells.

Anti-Pattern 4: Over-Engineering für Skalierung, die du nicht hast

Ein 5-Personen-Startup mit 3 Datenquellen braucht kein Data Vault.

Praktisches Playbook

Was für die meisten Teams beim Start einer neuen Lakehouse-Plattform 2026 funktioniert:

Phase 1 — Daten fließen lassen (Woche 1–4)

• Medallion-Layer aufsetzen (Bronze, Silver, Gold)
• Bronze: Raw-Ingestion mit Delta Lake oder Iceberg
• Silver: bereinigte, typed, deduplizierte Tabellen (noch keine formale Modellierung)
• Gold: aggregierte Views für sofortige Analytics-Needs

Phase 2 — Dimensionale Modellierung einführen (Monat 2–3)

• Gold-Layer als ordentliche Star Schemas für primäre BI-Use-Cases modellieren
• Fact-Tabellen-Grain, Dimension-Conformance, SCD-Strategie definieren

Phase 3 — Data Vault wenn nötig (Monat 4+, nur wenn gerechtfertigt)

• Data Vault in Silver einführen nur wenn Source-Komplexität oder Compliance es verlangt
• Mit dem höchstwertigen Integrations-Punkt starten (meist Customer oder Product)

FAQ

Brauche ich Data Vault, wenn ich DSGVO-konform sein muss? Nicht zwingend. Delta-Lake-Time-Travel reicht oft für DSGVO-Auskunft-Anforderungen. Data Vault wird nötig, wenn du Cross-Source-Linkage über lange Zeiträume nachweisen musst.

Welche Methodologie für mein 3-Personen-Daten-Team? Medallion + breite, denormalisierte Tabellen in Silver/Gold. Data Vault ist Overkill, Star Schema überraschend strikt.

Skaliert Data Vault wirklich? Ja, aber mit operativer Komplexität. Bekannte deutsche Implementierungen existieren in DAX-Unternehmen — meist mit eigenem Modellierungs-Team von 3+ Personen.

Wann Snowflake vs. Databricks für Medallion? Databricks für ML-heavy Workloads, Snowflake für BI-heavy. Beide unterstützen Medallion-Pattern nativ.

Stand: 14. Mai 2026.