Data Mesh or Data Lake? An Honest Take for Insurers

"Should we build a data mesh?" is the question every insurer's data leadership is being asked in 2026, usually by someone who read a compelling article. It's a genuine architectural choice with real implications — and it's also frequently the wrong question, asked to avoid a harder one.

Here's an honest take on data mesh versus a centralised lake for insurers, including the part the mesh advocates and the centralisation advocates both tend to skip.

What the two things actually are

Centralised (lake/lakehouse): one team owns a central platform; data from across the business flows into it; that team is responsible for it. The model most insurers have or are building.

Data mesh: a decentralised approach where each business domain — underwriting, claims, distribution — owns its own data as a "product," served to the rest of the org through agreed interfaces. A central team provides the platform and standards, but domains own their data.

The mesh pitch is that centralisation creates a bottleneck: one team can't understand every domain's data deeply enough, so it becomes a constraint everything queues behind. Decentralise ownership to the people who actually understand the data, and you scale.

Why mesh is genuinely appealing for insurance

Insurance has a real version of the problem mesh solves. Underwriting data, claims data, and actuarial data each require deep domain knowledge to model correctly. A central team will always understand each less well than the domain does — which is exactly why the "who owns the data?" question is so painful at most carriers.

Mesh's core insight — that the people who produce and understand data should own it — is correct, and it directly addresses insurance's federated-ownership gap.

Why mesh usually fails when insurers try it

And yet most insurance data-mesh initiatives struggle, for reasons worth being blunt about.

1. Mesh is an operating model, not a technology. It's fundamentally about ownership, accountability, and organisational design. Insurers often try to "buy a data mesh" as a platform, which misses the point entirely. If your domains won't accept accountability for their data, no tooling creates a mesh.

2. It demands data maturity most insurers don't have yet. Mesh assumes domains can produce well-modelled, quality-assured, documented data products with contracts and SLAs. If your domains currently can't reliably say what "active policy" means, asking them to publish a governed data product is several maturity levels too far. Mesh amplifies whatever discipline exists — and amplifies the absence of it just as faithfully.

3. It can entrench the silos it was meant to bridge. Done without strong shared standards and identity, "domain ownership" becomes "every domain does its own thing," and you've formalised fragmentation. The customer key that must span domains is exactly what a poorly-governed mesh fails to deliver.

4. It's often an escape from the real problem. This is the uncomfortable one. Debating mesh-versus-lake is more interesting than resolving customer identity, measuring data quality, and getting domains to agree on definitions. Teams reach for the architectural debate to avoid the unglamorous foundational work — and the architecture, whichever they pick, then sits on top of the same unresolved mess.

The honest guidance

If your data maturity is low — no reliable customer key, unmeasured quality, undefined ownership — do not start with mesh. You'll decentralise chaos. Build the foundations centrally first: identity resolution, quality measurement, agreed definitions, lineage. A capable central platform is the right move while you establish discipline.

If you're mature and hitting a genuine central bottleneck — the central team is a real constraint, domains are capable and want ownership, you have strong shared standards and identity — then mesh's principles are worth adopting, incrementally. Start with one or two capable domains publishing genuine data products, keep identity and standards central, and expand as it proves out.

For most insurers, the answer is a hybrid, and it's less about the label than the substance: a strong central platform providing identity, standards, quality tooling, and lineage, with domains progressively taking ownership of their data as their maturity grows. You don't pick mesh or lake; you build the shared foundation and shift ownership outward at the pace domains can carry it.

The question behind the question

When someone asks "should we build a data mesh?", the more useful questions underneath are: Can we identify a customer across domains today? Do our domains know and own what their data means? Do we measure quality? Is there lineage?

If the answer to those is no, the architecture debate is premature — fix those first, and the mesh-versus-lake choice becomes clearer and lower-stakes. If the answer is yes, you're mature enough that mesh's ideas can genuinely help.

Either way, the architecture is the frame, not the substance. The substance is identity, quality, ownership, and lineage — and no diagram, centralised or federated, delivers those for you.

We help insurers build the foundations — identity, quality, governance — that make any data architecture actually work. More at IntelliBooks.