In our global overview article, we introduced Data Mesh as a decentralized architectural model that shifts data ownership to business domains. Now it’s time to take a closer look at this disruptive and often misunderstood approach (where each person seems to have their own definition 🙃).

While architectures like Data Warehousing, Lakehouse, or Data Fabric are focused on physical or logical layers for managing data, Data Mesh is primarily about organizational design.

The purpose of this model is to answer the same recurring questions we hear in large companies 🤔: Who owns the data? How is it produced and consumed? What are the responsibilities of each team?

These questions might seem simple when you’re dealing with small teams working closely together. But once you’re in an enterprise dealing with huge data volume, with multiple IT and multiple data teams across countries or business units, the answer becomes less and less obvious 😕.

💡
So let’s take a step back and ask: what is a Data Mesh really? What types exist? And is it a real paradigm or just another buzzword that recently popped up?

Quick Recap ↻

Data Mesh - New

Data Mesh is not a product, nor a specific tool. It’s an organizational model based on four core principles:

  1. Domain Ownership: Each business domain is responsible for managing the ingestion, transformation, and delivery of its own data products (dashboards, APIs, machine learning outputs, etc.).
  2. Data as a Product: Data teams treat internal stakeholders (analysts, scientists, etc.) as customers, delivering high-quality and reliable data products.
  3. Self-Service Platform: A central team provides reusable tools and infrastructure: pipeline templates, deployment automation, monitoring, and data quality systems.
  4. Federated Governance: Enterprise-wide policies (like security, privacy, metadata) are defined centrally but enforced locally by each domain. This allows flexibility without losing compliance or standardization.

The philosophy is to move away from a centralized IT team that can’t keep up with business demands, and enable each team to manage its own data responsibly.

For example: Take a typical company with multiple business domains divided by a function (Sales, HR, Finance, etc), by countries or by business units. Each domain can have its own data team (Principle 1), deliver specific data products (Principle 2), and use the tools and governance rules provided by central IT (Principle 3 & 4).

✔️
The core idea is to distribute data responsibilities to teams closest to the business, while still keeping global governance and platform consistency.

Data Mesh Types

Data Mesh - Types

Let’s now move from theory to practice ! What does Data Mesh look like in real-life deployments? Here are the 3 main types of topologies often discussed:

  • Mesh Type 1: Logical Decentralization, Aligned Technologies
    – All domains use the same tech stack (same Data Lake, ETL tools, MDM, security, etc).
    – Data is logically separated (using folders, namespaces, or catalogs) but stored in the same shared platform.
  • Mesh Type 2: Physical Storage Separation, Aligned Technologies
    – Each domain owns its own Data Lake or Lakehouse, but uses the same core stack and standards.
    – This provides more autonomy but comes with added operational complexity.
  • Mesh Type 3: Full Decentralization
    – Each domain chooses its own infrastructure, cloud provider, storage format, and ETL stack.
    – While this gives full freedom, it leads to interoperability and cost issues.

As you might expect, Mesh Type 3 is mostly theoretical. In practice, it’s extremely difficult (and expensive…) to run one data domain on Azure, another on GCP, each with different tooling. This is why Data Mesh should be seen as a spectrum between centralization and decentralization. You can’t have full independence without trade-offs.

💡
In fact, most organizations aim for a Type 1 mesh where responsibilities are clearly distributed while infrastructure is shared and optimized. Some companies are forced into Type 2 setups like for legal or regulatory reasons requiring separate data lakes.

Real-World Implementation

Let’s begin by taking a practical example : a really large company (like S&P500-style) with multiple business units across regions. A realistic Data Mesh implementation could look like this:

  • A Global Data Office defines enterprise-wide standards (e.g. business term definitions, quality rules, governance). → Principle 4
  • A Group Data Lake is shared, but partitioned by business unit (folders, namespaces, catalogs).
  • Each Business Unit of each region manages its own stack (ETL tools, DWHs, dashboards), owns its own data, and publishes products for internal use or group-level consumption. → Principles 1 & 2
  • A central IT/platform team provides self-service capabilities and blueprints with an approved tech stack. → Principle 3
💪
This model aligns with Mesh Type 1. It lets you scale while maintaining operational control.

Wait, wait, wait ✋ ! At this moment, it’s important to step back and ask: how does Data Mesh fit into the broader data architecture landscape ? What about other models like Data Lakehouse or Data Fabric?

Problem : This is where many get confused, especially when they try to compare these approaches directly, when in fact they often address different issue.

Let’s clarify one common misconception: Data Mesh and Data Fabric (or other physical architectures) are not competing models. You can have, for each BU, a data domain, where we have : Data Domain A working with a Snowflake DWH, Data Domain B using a Databricks Lakehouse, Data Domain C storing data in a on-prem Data Lake.

In this context:

  • Data Mesh provides the organizational framework: it defines who owns which data, how data responsibilities are distributed across domains, and how each team is accountable for producing and maintaining its own data products.
  • Data Fabric acts as the technical layer that connects everything: it offers unified discovery, access, lineage, and governance across these distributed systems (regardless of whether they are Snowflake, Databricks, or a raw data lake).
✔️
In other words: Mesh defines “who does what” and Fabric defines “how to access it efficiently”.

Myths and Misconceptions

Also, Data Mesh is used mainly as a buzz word as the magic tool for all your problem. Let’s address some common false ideas about Data Mesh:

  • It solves all data problems → No. It creates new ones. More autonomy means more complexity to manage.
  • It replaces your Data Warehouse or Lake, so it’s efficient ! → False. You’ll likely end up with more, not fewer, storage layers (because of multiple data domains).
  • It’s easier than centralized models → It’s not. It’s harder to enforce consistency when having independent teams.
  • It means decentralizing everything → No. You still need central governance and shared platforms.
  • It’s the same as Data Fabric → Those are completely different approaches : one is organizational, second is technological.

Let’s be honest ! Full Data Mesh adoption is NOT HAPPENING in most companies today. And I will tell you why :

  • Not every domain has a data team. Functions like HR, Procurement, or even Sales often don’t have dedicated a data team. Assuming every domain can take full ownership of his data scope is unrealistic…
  • Most analytics products span multiple domains. Who owns a dashboard that combines data from HR, Finance, and CRM? Cross data-domain products are the norm, not the exception !
  • Is Single Version of the Truth dead ? Back in the 90s, data warehouses were designed to unify and standardize data. Are we now breaking that apart again by dividing everything into isolated domains?
  • Data integration is still hard. Different domains have different identifiers, naming conventions, levels of quality, etc.
  • Governance is already hard with one central team. Now imagine trying to enforce standards across ten separate teams with different levels of maturity.
  • No human resources here. Even centralized data teams struggle to hire skilled worker. Expecting each domain to staff its own data team just isn’t realistic.
  • And what about the cost ? Data Mesh sounds great in theory, but many of its early discussions simply ignored the financial and operational implications.

That said, let’s not throw the baby out with the bathwater 👶🏻 !

👉 In my view, the most valid use case for Data Mesh is when you have multiple business units or subsidiaries that can’t merge their data (for legal, operational, or compliance reasons). In that case, Data Mesh helps organize data ownership, and Data Fabric becomes the technical layer that connects everything across those silos.

❌
If you’re trying to split a company into domains like HR, Sales, and Finance and give each one its own platform, tech stack, and team ? That’s more likely to waste time and money than deliver value.

To conclude

Data Mesh is not an all-or-nothing model and is not be used everywhere ⚠️ ! Yes, it brings useful principles : clearer ownership, domain accountability, and more. But turning those principles into something that works in real life is a completely different story.

The truth is that most organizations aren’t ready. They don’t have the structure, the teams, or the culture to make a full data mesh work. And pretending otherwise just leads to over-engineered systems, fragmented platforms, and governance issues !

You don’t need to have a Data Mesh to improve your data architecture and to be data driven, and don’t forget :

  • Where centralization still brings value → keep it (SVOT, MDM, Fabric) .
  • Where decentralization is necessary → structure it (Mesh principles).
  • And where alignment is missing → fix it before scaling anything.

I hope this article helped cut through the hype and offered a more realistic view of this trending shining architecture model !

👉 If you want to learn more about Data Fabric, just click here.