Die Frage „Mesh oder DWH?" ist eine Scheindichotomie. Sie vermischt zwei Ebenen: Governance-Modell und Speicher-Architektur. Dieser Artikel trennt die Ebenen und zeigt, wie sie zusammenarbeiten.
Zwei verschiedene Ebenen
Data Warehouse / Lake / Lakehouse sind Antworten auf die Frage: Wo und wie speichern wir Daten, wie rechnen wir auf ihnen?
Data Mesh ist eine Antwort auf die Frage: Wer verantwortet welche Daten, wie werden sie gepflegt und genutzt?
Die Fragen sind orthogonal. Ein Unternehmen kann:
- Data Warehouse haben, ohne Mesh (typisch bei kleineren Organisationen)
- Data Mesh haben, das auf Data Lakes läuft (typisch bei größeren Tech-affinen Unternehmen)
- Data Mesh haben, das auf klassischen Data Warehouses läuft (häufig bei Enterprise-Transformationen)
Was Data Warehouse / Lake / Lakehouse wirklich ist
Data Warehouse: Strukturiertes, analytisches Datenhaltungs-System. Optimiert für aggregierte Abfragen. Historisch on-premise (Teradata, Netezza), heute cloud-nativ (Snowflake, BigQuery, Redshift).
Data Lake: Flexibles Datenhaltungs-System für strukturierte, semi-strukturierte und unstrukturierte Daten. Typisch Object Storage (S3, ADLS) mit Compute-Engines obendrauf.
Lakehouse: Hybrid-Architektur, die Warehouse-Funktionalität auf Lake-Storage umsetzt. Databricks, Snowflake's Iceberg-Support.
Alle drei sind Speicher- und Compute-Architekturen. Sie sagen nichts darüber, wer die Daten pflegt oder wie sie strukturiert organisiert sind.
Was Data Mesh zusätzlich bringt
Data Mesh antwortet auf Fragen, die kein Data Warehouse beantwortet:
- Wer ist verantwortlich für die Marketing-Kunden-Daten?
- Wie finde ich Daten, die ich nicht kenne?
- Wie kommuniziere ich Schema-Änderungen an alle Konsumenten?
- Wer entscheidet, ob ein neues Data Product priorisiert wird?
Das sind Governance-, Organisations- und Prozess-Fragen. Ein Data Warehouse kann sie technisch unterstützen (Catalog-Feature, Access-Management), aber nicht lösen.
Wann Data Warehouse allein reicht
Ein zentrales Data Warehouse ist ausreichend, wenn:
- Organisation < 500 Mitarbeiter
- Weniger als 5 ernsthafte Daten-Domänen
- Zentrales Data-Team kann Nachfrage bewältigen
- Daten sind überwiegend strukturiert und homogen
- Konsumenten sind überschaubar (< 20 aktive Nutzer)
In diesen Szenarien ist Mesh Overkill. Die Komplexität des Organisations-Modells rechtfertigt sich nicht.
Wann Mesh den Unterschied macht
Mesh wird relevant, wenn:
- Organisation > 500 Mitarbeiter
- 5+ unabhängige Daten-Domänen
- Zentrales Data-Team ist Bottleneck (Tickets-Warteschlangen, monatelange Wartezeiten)
- Daten-Nachfrage wächst schneller als zentrale Kapazität
- Konsumenten wollen eigenständig arbeiten
Dann transformiert Mesh die Organisation — aber nutzt weiterhin DWH/Lake als Speicher-Infrastruktur.
Die typische reale Architektur
In einem reifen Mesh sieht die Architektur oft so aus:
Speicher-Schicht: Cloud Data Warehouse (Snowflake) oder Lakehouse (Databricks). Zentrale Infrastruktur, betrieben vom Platform-Team.
Governance-Schicht: Data Catalog, Access-Control, Quality-Monitoring. Zentral definiert, dezentral genutzt.
Domain-Schicht: Jede Domäne arbeitet auf der Speicher-Infrastruktur, pflegt eigene Data Products, dokumentiert im Catalog.
Konsumenten-Schicht: Data Citizens aus allen Bereichen, die Data Products nutzen — via SQL, BI-Tools, APIs.
Das ist kein Entweder-Oder, sondern eine geschichtete Architektur, in der die Ebenen klare Rollen haben.
Migrations-Pfade
Vom klassischen DWH zum Mesh:
- Bestehendes DWH bleibt als Speicher-Substrat
- Governance-Schicht (Catalog, Policies) wird ergänzt
- Ownership wird schrittweise von zentralem Team auf Domänen verschoben
- Platform-Team transformiert sich zu Self-Serve-Builder
Dauer: 2–4 Jahre, je nach Ausgangslage.
Vom Data Lake zum Mesh: Oft einfacher, weil Data Lakes von Natur aus dezentralere Strukturen unterstützen. Trotzdem 2–3 Jahre.
Vom Mesh zurück zum zentralen DWH: Seltenen Sonderfall, meist nach gescheiterter Mesh-Einführung. Anzeichen: Reifegrad-Lücke nicht geschlossen, Kompetenz in Domänen fehlt, Governance zerfällt.
Die Tool-Verwirrung
Viele Tool-Anbieter vermarkten ihre Produkte als „Data Mesh Plattform". Ehrlich: Es gibt 2026 keine Platform, die Mesh vollständig abbildet — weil Mesh kein Tool-Problem ist.
Tools unterstützen Mesh:
- Data Catalogs (Atlan, DataHub, Collibra)
- Data Contract Tools (noch in Entwicklung)
- Data Quality Monitoring (Monte Carlo, Soda)
- Self-Serve Platform Builder (Atlan, Select Star)
Keine dieser Tools macht dich zum Mesh. Sie unterstützen das Modell — Implementierung bleibt organisational.
Lakehouse als Mesh-Enabler
Lakehouse-Architekturen (Databricks, Iceberg) sind oft gute Mesh-Substrate:
- Offener Storage (kein Vendor-Lock-in)
- Data Products können in verschiedenen Formaten existieren
- Multi-Engine-Compute (SQL, Spark, ML) auf gleichem Storage
- Governance-Features eingebaut
Aber auch hier: Das Tool allein macht kein Mesh.
Häufige Missverständnisse
Missverständnis 1 — „Mesh ersetzt DWH." Falsch. Mesh läuft auf DWH (oder Lake, oder Lakehouse).
Missverständnis 2 — „Mesh ist nur für Tech-Unternehmen." Falsch. Mesh hilft allen Organisationen, die groß und heterogen genug sind. Branche ist sekundär.
Missverständnis 3 — „Man hat entweder zentrales Team oder Mesh." Falsch. Auch im Mesh existiert ein zentrales Platform-Team. Es hat nur andere Aufgaben.
Missverständnis 4 — „DWH ist altmodisch, Mesh ist modern." Falsch. DWH hat 40+ Jahre Bewährung, Mesh ist 5 Jahre alt. Beide haben ihren Platz.
Verbindungen: Einführung für die Mesh-Prinzipien. Data Products als zentrales Artefakt. Organisationsmodell für Team-Strukturen.