Data Mesh vs Centralised Data Platforms for Mid-Market Growth

Growing Australian companies eventually hit the same wall: the data team that once served everyone can no longer keep up with demand from product, finance, marketing and operations at the same time. The instinct is often to reach for a new tool. The harder, more consequential decision is architectural — do you centralise data ownership in one platform team, or distribute it across domains in a data mesh? This is a decision about organisational design as much as technology, and getting it wrong is expensive to unwind.

What is a data mesh?

Data mesh is an organisational and architectural pattern where domain teams — not a central data team — own the data products relevant to their part of the business, publish them to a shared platform, and are accountable for their quality and documentation. It shifts data ownership to the people closest to the source systems, treating data as a product rather than a by-product of pipelines.

In practice this means a logistics domain team owns and publishes shipment and fulfilment data, a finance domain team owns billing and revenue data, and a thin central platform team provides the shared infrastructure, standards, and discoverability layer that ties it together. No single team is a bottleneck, but no single team is fully responsible for data quality across the business either — that responsibility is federated.

What is a centralised data platform?

A centralised data platform is a model where one team — typically a data engineering or platform function — owns ingestion, transformation, storage and governance for the whole organisation, and other teams consume data through that team's pipelines and warehouse. It is the more familiar pattern for companies moving from spreadsheets and siloed reporting to a proper data function.

Centralisation concentrates expertise, tooling decisions and quality control in one place. Requests from other teams flow through that team, which builds and maintains the pipelines, models the data, and enforces standards. This is the model most mid-market Australian scale-ups start with, because it is simpler to build and staff when a data function is small.

How do team structures differ between data mesh and centralised models?

Team structure is the clearest dividing line between the two approaches. A centralised model needs one strong, well-resourced data engineering team; a mesh needs data-literate engineers embedded in every domain team, plus a smaller platform team supporting them — which is a materially larger total investment in data skills across the organisation.

For a company with 50-300 employees and one or two dozen data consumers, a mesh often means asking product engineering teams to take on data product ownership they don't have capacity or appetite for. For a company with several hundred employees, multiple business units, and genuinely divergent domains — say, underwriting data in an insurtech and claims data in the same business — forcing everything through one central team becomes the bottleneck instead.

What governance overhead should you expect with each approach?

Centralised platforms carry governance in one place, which is simpler to audit but slower to change; mesh architectures distribute governance to domains, which scales better but requires more explicit standards, contracts, and tooling to stop the mesh from becoming disconnected, inconsistent silos. Neither approach removes the need for governance — it only changes where the effort sits.

In a centralised model, governance is largely a function of the platform team's discipline: schema standards, access controls, and lineage tracking live in one codebase and one set of runbooks. In a mesh, you need federated computational governance — shared standards for data contracts, interoperability, and access that every domain team is expected to follow, plus tooling that makes non-compliance visible. Standards such as ISO/IEC 38505 on data governance are a useful reference point for defining accountability regardless of which architecture you choose — the standard doesn't prescribe mesh or centralisation, but the accountability principles apply to both.

When does a data mesh suit a growing Australian data function?

A data mesh tends to suit organisations with genuinely distinct business domains, multiple product lines or business units, and enough engineering capacity in each domain to take on data ownership without slowing down their core roadmap. It is an organisational commitment, not a tooling purchase, and it works best when leadership is willing to fund data skills inside every domain team, not just in a central function.

Australian companies that have grown through acquisition, or that operate genuinely separate business units (for example, a logistics company with distinct freight and last-mile domains, or an insurer with separate underwriting and claims functions), are the more natural mesh candidates. If your data consumers are mostly asking for the same handful of reporting and analytics use cases, mesh's overhead rarely pays for itself.

When does a centralised platform make more sense?

A centralised data platform is usually the right starting point for scale-ups with 50-500 employees, a single core product, and a data function still being built out — which describes most of the mid-market companies we work with. It is faster to stand up, easier to govern with a small team, and gives leadership a single place to look for data quality and lineage questions.

The trade-off is that a central team can become a queue. If every new dashboard or model request has to go through the same two or three data engineers, that queue grows with the business. The fix is not always mesh — often it's better self-serve tooling, clearer prioritisation, and investment in the platform team, which we cover in our data infrastructure work.

How do the two approaches compare?

Dimension	Centralised platform	Data mesh
Team structure	One central data team	Data skills embedded in every domain, plus thin platform team
Speed to stand up	Faster	Slower — requires organisational buy-in first
Governance model	Single point of control	Federated, standards-driven
Best fit company stage	Early-to-mid scale-up, single core product	Larger scale-up or enterprise with distinct domains
Main risk	Central team becomes a bottleneck	Inconsistent quality across domains without strong standards
Total data-skills investment	Lower	Higher

Do you have to choose one or the other?

Most growing Australian companies don't need a pure version of either model — a common and pragmatic path is to centralise the platform layer (storage, pipelines, standards) while gradually federating ownership of specific high-value domains as they mature, rather than declaring a mesh transformation on day one.

This hybrid approach lets you keep governance manageable while giving your most data-mature domain teams — often the ones closest to the product or to revenue — more autonomy over the data they understand best. It's also a lower-risk way to test whether your organisation actually has the domain-level engineering capacity that a full mesh requires before committing to it everywhere.

Where does this fit with modernisation and AI plans?

Data architecture decisions rarely happen in isolation — they usually surface alongside a broader modernisation effort, a move off legacy systems, or a push to get AI initiatives off the ground. If your backend is still monolithic, the data architecture conversation is closely tied to application modernisation work, since domain boundaries in your data often mirror (or should mirror) domain boundaries in your codebase. And if AI is on the roadmap, the data foundation you choose now will shape what's realistic later — see our thinking on AI product strategy for how these decisions connect.

We've also written about the foundational work of getting data infrastructure right before layering AI on top, in our insights on building the foundation for AI.

Getting the decision right for your organisation

There is no universally correct answer between data mesh and centralised platforms — the right choice depends on your company's structure, the maturity of your domain teams, and how much organisational change you're prepared to fund. We're honest about this with every client: mesh is not a more advanced or more prestigious choice, it's a different trade-off that suits a specific set of circumstances.

If you're weighing up data architecture decisions for a growing Australian data function, we can help you work through the trade-offs against your actual team structure and growth plans, rather than a generic framework.