Data mesh or central warehouse: choosing without an ideology fight

Over the past two years, data mesh has completed its usual arc: first the evangelism, then the backlash, then the attempt to figure out where it actually works. In conversations with executives I see the same pattern - a team reads about data mesh, gets excited, and starts building the case for a migration. Or the opposite - the team heard about data mesh but never dug into it, and proposes building yet another warehouse by default.

Neither is the right starting point. The right starting point is the specific organisation and the specific problems it has.

What each approach actually solves

A centralised data warehouse solves one problem well: the organisation has a single place where data from different sources is collected, normalised, and available for analytics. This works well when the data team is small, the number of sources is manageable, and responsibility for data quality can be concentrated in one place.

Data mesh solves a different problem: what to do when there is a lot of data, many sources, many teams - and the central team has become a bottleneck that cannot keep up with all the requests, and data quality suffers because nobody close to the source is responsible for it.

These are not competing technologies. They are different organisational patterns that solve different problems.

Signs that a centralised warehouse fits

A few characteristics that point toward the centralised approach:

• The company has one or two core analytics needs, not dozens.
• The data is a few dozen tables from three to five source systems.
• There are no dedicated data people inside business units - just one shared analytics team.
• Response speed for analytical requests matters more than flexibility.
• Company size: under 500 to 1000 people.

In this case data mesh is architectural complexity without architectural benefit.

Signs it is time to think about decentralisation

Situations where the centralised model starts to crack:

• The central data team is overwhelmed with requests and cannot keep up.
• Business unit teams complain that data in the warehouse is stale or wrong, and nobody can fix it except by filing a ticket.
• Different departments argue about whose definition of "customer" or "revenue" is correct.
• Thousands of tables from dozens of systems, and nobody has a full picture.
• Several product teams want to work with data independently, without waiting in line.

These are signs that the organisational structure has outgrown the centralised model. Data mesh here is not a technical decision - it is an organisational one.

What is often confused

The most common mistake is treating data mesh as a set of tools. No tool makes data decentralised. Data mesh is about who owns the data and who is accountable for its quality. It is a decision about people and processes, not about a platform.

The second common source of confusion: "we want data mesh because it is modern." If there is no real bottleneck problem, the migration will create complexity without benefit.

Questions for making the decision

Before choosing an architecture, it is worth answering a few questions honestly:

1. What specifically hurts in your current data work - is it slowness, inaccuracy, inaccessibility, or something else?
2. How many teams work with data independently, and how much do their needs overlap?
3. Are there people inside the business units who can and want to own the data for their area?
4. What is harder - organising a centralised team, or agreeing on standards across decentralised teams?
5. If the number of data sources doubles in two years, which model handles it better?

Honest answers to these questions usually point in a clear direction - without needing to read another article about data mesh.