Data Mesh vs Data Fabric: Wann welches Pattern wirklich passt

"Data Mesh" und "Data Fabric" tauchen in jeder Enterprise-Architektur-Diskussion auf — oft austauschbar, oft falsch. Beide adressieren ein Problem: Wie skalierst du Datenzugriff und -qualität über eine große, verteilte Organisation, ohne Bottleneck oder Chaos zu schaffen?

TL;DR

• Data Mesh = Organisationsmodell (Domain-Ownership, Data-as-a-Product).
• Data Fabric = technisches Integrations-Pattern (Metadata-Layer, Virtualisierung).
• Beide können sich ergänzen: Fabric als Infrastruktur, die Mesh skalierbar macht.
• Pures Decentralization (Mesh ohne Discovery-Layer) endet im Chaos.
• Pures Fabric ohne organisatorisches Commitment endet als teures, ungenutztes Catalog-Tool.

Das Problem, das beide adressieren

Das klassische zentralisierte Warehouse funktioniert klein. Ab einer gewissen Größe bricht es:

• Zentrales Team wird Bottleneck — jeder Bedarf braucht Ticket
• Domainwissen liegt bei den Domains, nicht beim Zentralteam
• Quality leidet, wenn das verantwortliche Team vom Business-Kontext getrennt ist
• Governance ist über Dutzende Quellen nicht uniform durchsetzbar

Beide Patterns sind Antworten auf dieses Skalierungsversagen.

Was Data Mesh ist

Organisatorisches und architekturales Pattern (Zhamak Dehghani, 2019). Kern: Daten als Produkt, owned von der Domain, die sie produziert.

Die vier Prinzipien

1. Domain-Ownership Das Order-Team owned orders, das Customer-Team customers. Quality, Freshness und Accessibility sind Domain-Verantwortung — nicht des Zentralteams.

2. Data as a Product Jede Domain published Data-Products — versionierte, dokumentierte Datasets mit SLAs und Contracts. Discoverable, addressable, trustworthy, self-describing, interoperable.

3. Self-Serve-Platform Plattform-Team liefert Infrastruktur (Storage, Compute, Catalog, Observability), Domain-Teams bauen Products.

4. Federated Computational Governance Globale Rules zentral definiert, aber per Infrastruktur erzwungen — nicht durch manuelle Reviews. Policy as Code.

Was Mesh nicht ist

• Spezieller Tech-Stack (technologie-agnostisch)
• Eine Möglichkeit, kein Zentralteam zu haben (Plattform-Team existiert weiter)
• Lösung für kleine Organisationen
• Etwas, das du in einem Quartal implementierst

Was Data Fabric ist

Architekturpattern und Technologie-Kategorie für unified, automatisierten Zugriff über heterogene Quellen — egal wo die liegen, in welchem Format, von wem gemanagt.

Wo Mesh primär organisatorisch ist, ist Fabric primär technisch: Metadata-Management, automatisierte Integration, Active Metadata, Knowledge Graphs, AI-driven Discovery.

Kernkomponenten

Was Fabric ist und nicht ist

Ist:

• Technisches Integrationspattern
• Konzept-vendor-agnostisch, real von IBM, Informatica, Talend, Microsoft Fabric implementiert
• Für sprawling, geografisch verteilte Stores
• Primär Metadata- und Integrations-Story

Ist nicht:

• Neues Storage-Format oder Compute-Engine
• Weg, Daten nicht zu bewegen (bewegt sie, wo nötig)
• Lösung für Ownership-Probleme (das ist Mesh-Territorium)

Vergleich

Beide haben?

Ja — und die ausgefeiltesten Enterprise-Implementierungen kombinieren beide. Fabric liefert die Infrastruktur, die Mesh in der Praxis skalierbar macht.

• Mesh definiert Ownership, Product-Contracts, federated Governance.
• Fabric liefert Metadata-Layer, Discoverability, Virtualisierung.

Mesh ist die organisatorische Architektur, Fabric die technische Infrastruktur, die sie funktionieren lässt.

Wann Data Mesh?

Passt, wenn:

• Mehrere Domain-Teams mit starker Ownership-Kultur und Tech-Kapazität
• Zentraler Bottleneck ist real und messbar
• Leadership unterstützt Org-Change
• Plattform-Infrastruktur vorhanden oder baubar

Passt nicht, wenn:

• Org hat < 50–100 Engineers
• Domain-Teams haben keine Data-Engineering-Kapazität
• Leadership sieht Ownership als Risiko
• Basic-Quality-Probleme noch ungelöst

Wann Data Fabric?

Passt, wenn:

• Viele heterogene Quellsysteme (on-prem, multi-cloud, legacy)
• Virtualisierung ist Alternative zu zentralem Warehouse
• Automatisiertes Metadata-Management bei Skalierung Priorität
• Budget für Enterprise-Plattform vorhanden

Weniger nötig, wenn:

• Landschaft relativ homogen (eine Cloud)
• Volumen und Teamgröße rechtfertigen Komplexität nicht
• ETL/ELT löst das Integrationsproblem ausreichend

Unbequeme Wahrheiten

Data Mesh ist philosophisch überzeugend und praktisch hart. Die meisten "Mesh"-Implementierungen sind unvollständig — Domain-Ownership-Sprache ohne Federated Governance oder Self-Serve-Platform. Resultat: dezentrales Chaos statt distributed Ownership.

Data Fabric ist oft Vendor-Marketing. Capability ist real, aber viele Enterprise-Fabric-Deployments werden teure Catalog-Tools, die kaum genutzt werden, weil sie nicht für die echten Consumer-Workflows gebaut wurden.

Keines ist eine Abkürzung um harte organisatorische oder technische Arbeit.

Praktische Startpunkte

Mesh aber noch nicht skaliert:

• Data-Product-Thinking auf meist-konsumierte Datasets anwenden
• Data-Contract pro Set schreiben
• Quality-Ownership zur produzierenden Domain verschieben
• Lightweight Self-Serve-Plattform mit dbt + Catalog

Fabric aber kein Voll-Implementation:

• Investiere zuerst in guten Catalog (OpenMetadata, DataHub — beide OSS)
• Metadata über Quellen standardisieren
• SQL-basierte Virtualisierung (DuckDB, Trino) für Cross-Source-Queries

FAQ

Können DACH-Mittelständler:innen Mesh sinnvoll einführen? Unter 50 Engineers selten. Daten-Product-Thinking auf einzelne Datasets dagegen schon.

Welches passt zu DSGVO besser? Beide gehen DSGVO-konform. Mesh erzwingt Ownership-Klarheit, was Auskunftsrechte vereinfacht.

Was kommt zuerst, Mesh oder Fabric? Mesh ohne Fabric-ähnliche Infrastruktur (mindestens ein Catalog) skaliert nicht. Fabric ohne Mesh-Diskurs wird oft unter-genutzt.

Welche Vendor-Optionen für Fabric in EU? Microsoft Fabric in West Europe, Informatica CDGC, IBM Cloud Pak for Data. Alle haben EU-Hosting.

Stand: 14. Mai 2026.