A question that mixes two decisions
"Should we build a lakehouse or a data mesh?" is one of the most common questions in data strategy, and one of the most confused.
A data warehouse, a data lake and a lakehouse are answers to a technical question: where data is stored, in what form, and how it is processed. A data mesh is an answer to an organizational question: who owns data, who is accountable for its quality, and how governance works across a large enterprise. Data fabric, the fifth term that often joins the list, is mostly about metadata and integration across systems you cannot consolidate.
Comparing a lakehouse with a data mesh is like comparing an office building with a reporting structure. You need both, and each constrains the other, but they are not alternatives.
Figure 1
Two decisions, not four options
Choose one answer on each axis. Data fabric is a metadata and integration layer that can sit across either.
Decision 1 · Technical
Where is data stored and processed?
- Data warehouse
- Data lake
- LakehouseDefault for new work
Decision 2 · Organizational
Who owns and governs it?
- Centralized team
- Mesh-lite: domain data products on a central platformPractical default
- Data mesh: federated ownership
Data fabric spans both: an automated, metadata-driven layer that connects data across systems you cannot consolidate.
Each pattern was a reaction to the last one's failure
The history explains the confusion. Each idea arrived to fix a specific problem with its predecessor.
Figure 2
Each idea answered the last one's failure
Storage patterns, ownership models and the critiques between them
Early 1990s
Inmon defines the data warehouse; Kimball's dimensional modeling follows (1996)
Oct 2010
James Dixon coins “data lake”
Jul 2014
Gartner warns of the “data lake fallacy”
May 2019
Zhamak Dehghani proposes data mesh; four principles follow in Dec 2020
Jan 2021
Lakehouse paper presented at CIDR
2022
Gartner Hype Cycle reportedly labels data mesh “obsolete before plateau”
Apr 2025
Thoughtworks moves data product thinking to Adopt
Feb 2026
Apache Polaris (Iceberg catalog) becomes a top-level Apache project
The data warehouse (early 1990s) gave organizations a single, integrated, historical store for reporting. Bill Inmon defined it as subject-oriented, integrated, time-variant and non-volatile; Ralph Kimball made it practical with dimensional modeling and conformed dimensions. Its weakness was rigidity: everything had to be modeled before it could be loaded, and a central team became the bottleneck.
The data lake (2010) flipped the order. James Dixon, who coined the term, contrasted raw data in its natural state with pre-packaged data marts. Land everything cheaply, model it later. By 2014 Gartner was warning of the "data lake fallacy": without shared definitions, governance and access control, lakes accumulated data nobody trusted. Most organizations ended up running a lake and a warehouse, copying data between them.
The lakehouse (2021) attacked that two-tier pattern. The CIDR paper that defined it, written by Databricks' founders, argued that copying data from lake to warehouse caused staleness, duplicated pipelines and extra cost, and proposed warehouse-grade transactions and management directly on open files in low-cost storage.
The data mesh (2019 and 2020) attacked a different problem. Zhamak Dehghani, then at Thoughtworks, argued that a central data team becomes a bottleneck however good its technology, and proposed four principles: domain ownership, data as a product, a self-serve platform, and federated computational governance.
The storage decision: the lakehouse largely won
On the technical axis, the argument has largely settled.
| Data warehouse | Data lake | Lakehouse | |
|---|---|---|---|
| Data stored as | Modeled tables in a managed engine | Raw files in object storage | Open-format tables on object storage |
| Best for | Governed BI and reporting | Cheap landing of raw and unstructured data | Both, plus ML and AI on one copy |
| Main risk | Rigidity and central bottleneck | Becoming a "swamp" | Catalog lock-in and table maintenance overhead |
| Multi-engine access | Limited | Easy but ungoverned | Possible through open catalogs |
What made the lakehouse viable is the open table format: Apache Iceberg, Delta Lake and Apache Hudi add transactions, schema evolution and time travel on top of Parquet files. Iceberg's specification now lists versions 1 to 3 as complete, with version 3 adding semi-structured "variant" data, row lineage and deletion vectors. Translation tools such as Apache XTable can expose one set of files in more than one format.
Figure 3
The open lakehouse stack
Lower layers are converging on open standards. The catalog is where control, and lock-in, now sits.
- AI agents, BI and applicationsDashboards, notebooks, assistants
- Semantic layerGoverned metrics and business definitions
- Query and processing enginesSQL warehouses, Spark, streaming, ML
- Catalog and access policyIceberg REST catalogs such as Apache Polaris; Unity Catalog
- Open table formatApache Iceberg, Delta Lake, Apache Hudi
- Open file formatApache Parquet
- Object storageIn-region cloud or on-premises storage
Two consequences follow. First, the file format matters less than it used to; the catalog matters more. Apache Polaris, an Iceberg catalog that became an Apache top-level project in February 2026, and the open-sourced Unity Catalog compete to be the place where tables are registered and access policies live. As our Snowflake and Databricks comparison explains, that layer is now where lock-in sits. Second, "warehouse versus lakehouse" is increasingly a product choice, not an architecture choice, since major warehouses now read and write open tables too.
The pure data lake, without a table format and catalog, is hard to justify for new work.
The ownership decision: mesh's real legacy is data products
On the organizational axis, the evidence is more interesting.
Data mesh generated enormous interest and a mixed track record. Gartner's 2022 Hype Cycle for data management, as widely reported, labeled it likely to be "obsolete before plateau". Thoughtworks, where the idea originated, moved it from Assess to Trial on its Technology Radar and later retired the entry, cautioning that vendors were distracting from the hard organizational work.
An interview study of 15 practitioners who had implemented data mesh found three recurring obstacles: the shift to federated governance, redistributing responsibility for data products to business domains, and poor understanding of the concept itself, including the habit of relabeling existing centralized stores as "mesh" and every dataset as a "product".
Yet one idea from data mesh has clearly survived. In April 2025 Thoughtworks moved data product thinking, treating data as a product with owners, consumers, quality measures and a lifecycle, to Adopt, its strongest recommendation, and stated that it applies whether an organization uses a data mesh or a lakehouse.
Real implementations point the same way. JPMorgan Chase described data products owned by product owners and shared in place through a central catalog. Zalando, one of the early public mesh adopters, describes its current platform as domain-owned catalogs combined with a shared central catalog, governed views and centrally defined metrics. Ownership was decentralized; governance and semantics were recentralized.
The practical pattern for most enterprises is therefore "mesh-lite": a small number of business domains own and publish data products, on a central self-serve platform, with central standards for security, quality and business definitions. Full decentralization comes later, if ever, and only for domains with the engineering capacity to carry it.
AI moves the bottleneck from storage to meaning
AI workloads strengthen both conclusions.
On storage, AI needs unstructured content such as documents, images, logs and transcripts alongside structured tables, and it needs several engines to reach the same governed data. That favors open formats and a single governed catalog.
On ownership, AI exposes every weakness in definitions and quality. Gartner reported in February 2025 that 63% of organizations either lacked or were unsure whether they had the right data management practices for AI, and predicted that organizations would abandon 60% of AI projects unsupported by AI-ready data through 2026. A lakehouse full of inconsistently defined data does not become AI-ready because a model can query it. It becomes a faster way to produce confident wrong answers.
The investment that matters most is therefore the least glamorous one: governed metadata and a semantic layer that define business terms once, and data products with owners who are accountable for them.
What goes wrong with each
| Pattern | Typical failure | Early warning sign |
|---|---|---|
| Data warehouse | Central team becomes the bottleneck; new data takes months | Business units building shadow databases and spreadsheets |
| Data lake | Swamp: data nobody trusts or can find | Growing storage, flat usage, no owners for datasets |
| Lakehouse | Old problems on new technology; catalog lock-in; unmanaged small files | Same governance complaints as before the migration |
| Data mesh | Relabeling without change; domains without capacity | "Data products" with no consumers, owners or quality measures |
| Data fabric | Automation built on poor metadata | Catalog coverage too low to drive the automation |
The common thread is that the failures are mostly organizational, not technical. A new architecture rarely fixes an ownership problem.
Choosing: one answer on each axis
Figure 4
A practical decision guide
Answers combine. Most enterprises end up at questions 2 and 3.
- 1
Is most of your analytics structured BI, run by one central team?
If yes: A warehouse engine, ideally on open tables, is enough. Keep ownership central. - 2
Do you need unstructured data, ML or AI on the same governed data?
If yes: Lakehouse on open table formats, with one governed catalog. - 3
Is the central team a bottleneck, with domains that have engineering capacity?
If yes: Add domain-owned data products on the central platform (mesh-lite). - 4
Must you connect many systems you cannot consolidate?
If yes: Add a metadata-driven fabric layer, if catalog coverage is good enough. - 5
Are you a Saudi public entity or partner?
If yes: Map the design to NDMO architecture and data sharing specifications.
The Gulf view
In Saudi Arabia, data architecture is not only a design choice; it is a documented compliance requirement. The NDMO Data Management and Personal Data Protection Standards require entities to define current and target data architectures and the gap between them. Specification DAM.3.4 requires documented requirements for a data lake environment based on a vendor-neutral big data reference framework, while the data sharing specifications describe ETL into a data warehouse store and ELT of unstructured data into a data lake.
That wording reflects the two-tier pattern the lakehouse was designed to replace. Entities adopting a lakehouse should document explicitly how one platform satisfies both sets of requirements, and reuse their target-architecture decision as the compliance deliverable rather than producing a separate document. Our NDMO implementation guide covers the wider standards.
At national level, both countries have made large central platforms the backbone of government data. Saudi Arabia's National Data Lake, operated by SDAIA, hosts data from hundreds of government systems across dozens of entities. Dubai's Data and AI Platform, launched by Digital Dubai in September 2024, is described as built on an integrated data fabric with decentralized data exchange. Both illustrate the same principle: central platforms with distributed ownership of data.
Sovereignty also favors open formats. Keeping data in in-country object storage, in an open format that more than one engine can read, reduces the cost of changing providers or regions as sovereign cloud options in the Gulf expand.
What to do next
- Separate the two decisions in your strategy documents: a storage and processing pattern, and an ownership and governance model.
- Default to open table formats for new analytical data, and choose your catalog as carefully as you would choose a database.
- Pick two or three domains with real demand and capacity to own data products first, each with a named owner, consumers and quality measures.
- Fund the semantic layer and metadata explicitly as AI foundations, not as documentation.
- Retire the second copy. Where a lake and a warehouse hold the same data, plan which one goes.
- In Saudi Arabia, map the target architecture to NDMO's architecture and sharing specifications so one design serves both delivery and compliance.
Frequently asked questions
What is the difference between a data lakehouse and a data mesh?
A lakehouse is a technical architecture that stores data as open-format tables on low-cost storage with warehouse-grade management. A data mesh is an organizational model that gives business domains ownership of data products under federated governance. You can run a data mesh on a lakehouse.
Is data mesh dead?
The full decentralized model proved hard to implement, and analysts cooled on it after 2022. Its core idea, treating data as a product with owners and consumers, is now widely recommended, including by Thoughtworks, where data mesh originated.
Do we still need a data warehouse?
You still need warehouse capabilities: modeled, governed, high-performance data for reporting. Increasingly they run on a lakehouse or on warehouse engines that read open table formats, rather than in a separate proprietary copy.
What is the difference between data mesh and data fabric?
Data mesh is about ownership: domains own and publish data products. Data fabric is about integration: an automated, metadata-driven layer that connects data across many systems. They address different problems and can be combined.
Sources and further reading
- Lakehouse: A New Generation of Open Platforms, Armbrust et al., CIDR 2021.
- How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh, Zhamak Dehghani, 20 May 2019; Data Mesh Principles and Logical Architecture, 3 December 2020.
- Gartner Says Beware of the Data Lake Fallacy, Gartner, 28 July 2014.
- Lack of AI-Ready Data Puts AI Projects at Risk, Gartner, 26 February 2025.
- Towards Avoiding the Data Mess, Bode et al., 2023.
- Technology Radar: Data product thinking, Thoughtworks, April 2025.
- Apache Iceberg specification; Apache Polaris top-level project announcement; Apache XTable.
- How JPMorgan Chase built a data mesh architecture, AWS Big Data Blog, co-authored with JPMorgan Chase.
- How Zalando built a unified data foundation, Databricks blog, 9 April 2026.
- Dubai Data and AI Platform launch, Digital Dubai, 26 September 2024.
- Data Management and Personal Data Protection Standards, v1.5, NDMO.