Medallion, lakehouse, data mesh. Three vocabularies, two architectural patterns, one organisational question. In the last eighteen months we have seen each sold back to us as a silver bullet. None of them is. The choice between them is organisational before it is technical.
The three patterns, briefly
Briefly, because the marketing has obscured how simple they are.
Medallion
A layering convention: bronze (raw), silver (cleaned, conformed), gold (business-ready). It does not specify storage, compute, or ownership. It is a naming discipline, not an architecture. Very useful inside a single domain or a single platform. Not, on its own, an answer to any enterprise-level question.
Lakehouse
A platform pattern: a single storage layer (object storage, Delta/Iceberg/Hudi) serving both analytical and ML workloads, with transactional guarantees on top. Replaces the warehouse/lake dichotomy. The dominant pattern for new builds in 2026 for good reason — it removes a class of integration problems. But it is a platform choice, not an operating-model choice.
Data mesh
An operating model: domain-owned data products, with a central platform team providing self-service infrastructure and federated governance. It is an organisational claim — that centralised data teams cannot keep up with enterprise demand, and that data should be owned where it is produced. It is not a platform; it is a way of running one.
The decision tree that matters
Most clients ask "which pattern should we pick?" when the question is "what pattern does our organisation actually support?". A decision tree:
How many real data domains do you have?
"Real" means: distinct business units with their own leadership, budget and accountability. Fewer than three — a mesh is overhead with no return. Three to ten — a mesh may help, if leadership wants it. More than ten — a mesh is likely necessary, because central teams cannot scale to match. This is the most important question. It is organisational, not technical.
Do your domains have data people?
Mesh requires domain teams that can own a data product end-to-end. If your marketing team cannot support a single analyst, declaring the "marketing data product" their responsibility is a policy, not a reality. You will own it centrally anyway. Start centrally, and move to mesh only as domains become ready.
How strong is your central platform team?
Mesh without a strong platform team is chaos. The platform team provides the paved road: self-service ingestion, governance-as-code, observability, cost controls. If you do not have this team, do not adopt mesh. Build the team first.
What is your regulator like?
Some regulated environments — for example, prudential supervision in specialty insurance — expect centralised accountability for the data used in statutory reporting. This is compatible with mesh, but only if the federated governance is strong enough to demonstrate lineage, ownership and control. If your governance is aspirational rather than operational, mesh will put you offside with the regulator.
What we typically recommend
Most mid-market clients, even at 500–2000 headcount, are better served by a lakehouse with a medallion convention, operated by a central data platform team, with domain "data product owners" who are analysts or product managers rather than fully-staffed data teams. This is a pragmatic middle path — the benefits of lakehouse economics, the discipline of medallion layering, and the seeds of mesh (named owners, product thinking) without the organisational burden of a full mesh operating model.
Organisations that have truly decentralised — usually large, complex, often post-merger — can go further. The three G15 housing associations we work with each have some form of mesh in the five-year roadmap. None of them expects to be there in eighteen months.
A word on Iceberg vs. Delta vs. Hudi
Ask any engineer, get a different answer. Ask us, and the honest answer is: for most enterprises in 2026, the table format matters less than the operational discipline around it. We ship Delta on Databricks and Iceberg on Snowflake / AWS; both are production-ready. We would not recommend a format change as the reason to do a migration. We would recommend a platform change if the platform is the pain.
What we do not recommend
- Lakehouse without a central platform team. You will reinvent the same plumbing in six domains and lose the efficiency that is supposed to pay for the migration.
- Medallion in isolation. Naming conventions do not solve organisational problems. If you cannot answer "who owns silver for the finance domain?", the bronze/silver/gold labels are decoration.
- Mesh without readiness. Declaring domains as product owners before they can operate data products results in data debt that will take years to unwind.
- Mesh to escape central accountability. If the real motive is "we do not want IT to be the blocker any more", the answer is a better platform team, not a new operating model.
Our bias, stated openly
We build lakehouses on Databricks and Snowflake every month. We deliver mesh-adjacent operating models when the organisation can support them. We have walked away from two engagements in the last year where the client wanted us to declare mesh on a Monday and ship it on a Friday. We will decline those again.
The pattern that works in 2026 is the one your organisation can actually run. That is not a slogan — it is the part of the choice that nobody puts on a slide.