Data Mesh vs. Data Lakehouse: Was CDOs 2026 wirklich entscheiden müssen

Eine global tätige Retailbank hat kkThe average number of new users each existing user generates through referrals. Above 1.0, growth compounds on itself and becomes exponential.Vollständige Definition ansehen →ürzlich 18 Monate und rund 40 Millionen Dollar in die Migration ihrer analytischen Workloads auf ein zentrales Cloud-Data-LakehouseLakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.Vollständige Definition ansehen → gesteckt, nur um festzustellen, dass ihre regionalen Datenteams in Asien-Pazifik und Lateinamerika still und leise ihre eigenen Pipelines daneben aufgebaut hatten. Die zentrale Plattform war technisch solide. Das Organisationsmodell darunter nicht. Das ist keine Geschichte über technisches Versagen. Es ist eine Geschichte über Architecture Governance, und 2026 spielt sie sich in irgendeiner Variante in fast jedem Großunternehmen ab.

Die Diskussion über moderne Datenarchitektur hat sich in den letzten zwei Jahren deutlich zugespitzt. CDOs fragen nicht mehr: „Sollen wir in die Cloud?" Sie fragen, welches Architekturmuster die richtige Balance aus Geschwindigkeit, Kontrolle, Kosten und analytischer Leistungsfähigkeit im großen MaMaUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Vollständige Definition ansehen →ßstab liefert.

Die zwei dominierenden Paradigmen und wo sie tatsächlich stehen

Das Data LakehouseData LakehouseA hybrid architecture combining the flexibility of a data lake with the analytical capabilities of a data warehouse, on a single storage layer.Vollständige Definition ansehen →, popularisiert von Databricks (ein Anbieter mit direktem kommerziellem Interesse an dem Konzept) und aufgegriffen von Snowflake sowie von Anwendern von Apache Iceberg, verbindet den günstigen Storage eines Data LakeData LakeA data lake is a centralized repository that stores large volumes of raw data in its native format, from structured tables to unstructured files, until needed.Vollständige Definition ansehen → mit der Abfrageleistung und den Governance-Funktionen eines Data WarehouseData WarehouseA central repository that consolidates data from many source systems into a structured, query-optimized store designed for analytics, reporting, and business intelligence.Vollständige Definition ansehen →. Das ist eine überzeugende technische Konsolidierung. Die eigenen Benchmarks von Databricks zeigen erhebliche Kostenvorteile gegenüber getrennten Warehouse-plus-Lake-Setups, allerdings sollten diese Zahlen als Anbieterangaben gelesen und vor Beschaffungsentscheidungen mit unabhängigen Bewertungen von Häusern wie Gartner oder IDC abgeglichen werden.

Data MeshData MeshData Mesh is a decentralized approach to data architecture and organization where domain teams own and serve their data as products, governed by shared standards.Vollständige Definition ansehen →, formuliert von Zhamak Dehghani und inzwischen in unterschiedlicher Ausprägung bei Unternehmen wie JPMorgan Chase, Zalando und Intuit institutionalisiert, ist eine grundlegend andere Idee. Es ist in erster Linie keine Technologieentscheidung. Es ist ein Organisations- und Ownership-Modell: Daten als Produkt behandeln, Domänenteams die Verantwortung für ihre Datenbestände übertragen, Governance föderieren statt zentralisieren. Die Architektur folgt aus diesen Prinzipien, sie treibt sie nicht.

Die Verwirrung in den meisten Gesprächen über Unternehmensarchitektur entsteht dadurch, dass beide als konkurrierende Lösungen für dasselbe Problem behandelt werden. Das sind sie nicht. Ein Data Lakehouse beantwortet die Frage, wie Daten effizient gespeichert und abgefragt werden. Ein Data Mesh beantwortet die Frage, wer in einer verteilten Organisation für Datenqualität, Auffindbarkeit und Eignung für den Einsatzzweck verantwortlich ist.

Wo die Adoption tatsächlich steht

In Großunternehmen aus Financial Services, Industrie und Konsumgüterbranche sieht das Muster 2026 in etwa so aus: Zentrale Lakehouses oder Cloud Warehouses bleiben die dominierende physische Architektur für analytische Workloads, während Data-Mesh-Prinzipien, insbesondere Domain Ownership und das Denken in Datenprodukten, als Operating Model darüber gelegt werden. Zalando hat schon 2021 relativ detaillierte Berichte über seine Mesh-Implementierung veröffentlicht, und zu den ehrlichen Erkenntnissen aus diesen Case Studies gehört der erhebliche Aufwand für Platform Engineering und kulturellen Wandel, der nötig ist, bevor Domänenteams ihre Datenprodukte wirklich besitzen können.

Kleinere Organisationen, typischerweise unter 2.000 Mitarbeitenden oder mit weniger als einem Dutzend analytischer Domänen, haben selten genug Skalierung, um eine vollständige Mesh-Einführung zu rechtfertigen. Der Koordinationsaufwand übersteigt den Nutzen. Für sie ist ein gut regiertes zentrales Lakehouse mit klaren Data-Stewardship-Rollen fast immer die pragmatischere Antwort.

Was das für den CDO bedeutet

Die erste Konsequenz: Das Architekturgespräch, das Sie mit Ihrem CTO oder Ihrem Cloud-Anbieter führen, ist wahrscheinlich nicht das Gespräch, das zuerst geführt werden sollte. Die relevanten Fragen sind organisatorisch: Wie viele eigenständige Geschäftsdomänen erzeugen Daten? Haben diese Domänenteams die Engineering-Reife, um Datenpipelines zu betreiben und SLAs auf Datenprodukte einzuhalten? Gibt es genug domänenübergreifende Datennutzung, um die Investition in eine gemeinsame Plattformschicht zu rechtfertigen?

Lautet die Antwort auf die letzte Frage ja, und in den meisten Großunternehmen tut sie das, dann ist der praktische Weg ein hybrider. Eine physische Plattform (Lakehouse, Cloud Warehouse oder eine Kombination, vermittelt über etwas wie Apache Iceberg als offenes Tabellenformat) übernimmt Storage und Compute. Ein Ownership-Modell für Datenprodukte übernimmt Verantwortlichkeit und Qualität. Föderierte Governance, bei der ein zentrales CDO-Office Standards setzt und Domänenteams sie umsetzen, übernimmt Compliance und Auffindbarkeit.

Die zweite Konsequenz betrifft die Kostensteuerung. Cloud-Datenplattformen können erhebliche und oft undurchsichtige Compute-Kosten erzeugen, gerade wenn mehr Teams Zugriff erhalten und schlecht optimierte Abfragen laufen lassen. Snowflake hat Resource Monitors und Query-Acceleration-Funktionen genau deshalb eingeführt, weil unkontrollierter Verbrauch für viele Kunden zu einem echten Budgetproblem wurde. CDOs, die die Plattform als IT-Thema und nicht als Thema der Finanzsteuerung behandeln, werden irgendwann unangenehme Gespräche mit ihrem CFO führen.

Drittens zählt das Talentmodell genauso viel wie das Technologiemodell. Data Mesh verlangt insbesondere einen Typ von Data Engineer, der in einer Geschäftsdomäne verankert ist, die Datensemantik dieser Domäne versteht und neben technischen Fähigkeiten ein Gespür für Produktmanagement mitbringt. Dieses Profil ist knapp und teuer. Wenn Ihre Organisation solche Leute realistisch nicht einstellen oder entwickeln kann, wird der architektonische Anspruch ins Stocken geraten, unabhängig von der gewählten Plattform.

Praktische Entscheidungen, die jetzt anstehen

• Prüfen Sie Ihre aktuelle Architektur nicht anhand des Technologie-Stacks, sondern anhand der Verantwortlichkeiten: Können Sie für jeden wesentlichen Datenbestand benennen, wer für dessen Qualität verantwortlich ist und wer der erklärte Konsument ist?
• Definieren Sie vor jeder Plattformmigration, was „Datenprodukt" in Ihrem organisatorischen Kontext bedeutet. Der Begriff wird so lose verwendet, dass ererThe ratio of interactions (likes, comments, shares) to reach for a given piece of content, used to gauge how well audiences respond relative to how many people saw it.Vollständige Definition ansehen → ohne gemeinsame Definition zu einem Label statt zu einer Praxis wird.
• Wenn Sie Lakehouse-Anbieter bewerten, holen Sie unabhängige Benchmark-Daten von Forrester, IDC oder aus Ihrem eigenen Proof of Concept, anstatt sich auf die Performance-Vergleiche der Anbieter zu verlassen. Databricks, Snowflake und Google (mit BigQuery) haben jeweils kommerzielle Gründe, ihre Zahlen vorteilhaft darzustellen.
• Föderierte Governance braucht ein funktionierendes zentrales Standardgremium, bevor Sie dezentralisieren. Teams können ihre Datenprodukte nicht verantwortungsvoll besitzen, wenn sie nicht wissen, wie die Unternehmensstandards für Metadaten, Lineage und Zugriffskontrolle tatsächlich aussehen.
• Pilotieren Sie Ownership für Datenprodukte mit einer oder zwei Domänen, die schon über starke Engineering-Kompetenz und klare Geschäftsmetriken verfügen. Skalieren Sie das Modell erst, wenn Sie verstanden haben, was der Betrieb tatsächlich kostet.

Die CDOs, die in den letzten Jahren bei moderner Datenarchitektur am weitesten gekommen sind, sind nicht zwangsläufig die, die die ausgefeilteste Plattform gewählt haben. Es sind die, die zuerst die Ownership-Frage geklärt und die Technologieentscheidung aus dieser Klarheit abgeleitet haben. Diese Reihenfolge schlagen Anbieter aus naheliegenden Gründen selten vor.