Architecture Patterns

Data Mesh Architecture

Term 59 of 68 in the ERPStack technical glossary

What is Data Mesh Architecture?

Data Mesh is a decentralized data architecture that treats data as a product, owned and published by domain teams rather than a central data engineering team, enabling self-service analytics without data warehouse bottlenecks.

Data Mesh Architecture at a glance

Principles: 4: domain ownership, data as a product, self-serve platform, federated governance
Ownership: The team that produces the data owns its quality and its 1 published contract
Prerequisite: Enough domain teams to justify it — below roughly 3, a central warehouse is simpler
Platform layer: 1 shared toolchain so a domain publishes a dataset without building infrastructure
Built with: PostgreSQL 18 and ClickHouse as domain stores, Apache Kafka for publication, Terraform and GitHub Actions as the shared platform, MongoDB Atlas where a domain needs documents
Numbers that matter: 4 principles; below roughly 3 domain teams a warehouse wins; 1 governance standard, N implementations; 12 incompatible islands is the failure mode
Compare with: 1 central warehouse, or ClickHouse and MongoDB Atlas operated by 1 platform team for N domains
Platform toolchain: Terraform and GitHub Actions as the shared platform, Apache Kafka for publication, PostgreSQL 18, ClickHouse and MongoDB Atlas as domain stores, Docker and Kubernetes runtimes, and OpenTelemetry Observability across pipelines
Product contract: 4 promises per data product — named owner, versioned schema, stated refresh cadence, 1 quality guarantee
Where it fits: manufacturing and logistics groups with 5 or more domain teams. Below that, 1 warehouse on PostgreSQL 18 and ClickHouse costs less to run than 5 federated ones.
Governance in practice: 1 shared standard for identity, retention, RBAC and SSO applied by every domain, so a GDPR request or a SOC 2 sample gets 1 answer across PostgreSQL 18, the ClickHouse analytics database and MongoDB Atlas rather than 5.

How Data Mesh Architecture works in production

Traditional data architectures force all business data through a central data lake or warehouse managed by a single team — creating a bottleneck as data volume grows. Data Mesh distributes ownership: the 'Orders' domain team owns and publishes their order data product; the 'Finance' team owns the revenue data product. Cross-domain consumers subscribe to these products via standardized APIs. This pattern dramatically reduces time-to-insight for large enterprises.

The ERPStack approach to Data Mesh Architecture

We implement Data Mesh principles for enterprise ERP clients by defining domain-owned PostgreSQL schemas with documented API contracts for cross-domain data access, enabling BI tools to query domain data without central ETL pipelines.

Related Resources

Frequently asked questions about Data Mesh Architecture

What problem does Mesh Architecture address?

The central data team as a bottleneck. In a warehouse model, 1 team owns pipelines for domains it does not understand, so every schema change upstream silently breaks a report downstream. Data Mesh Architecture moves ownership to the domain that produces the data and makes them publish it as a product with a contract, documentation and quality expectations attached.

How is a data product different from a table?

By the promises around it. Under Data Mesh Architecture a data product has a named owner, a versioned schema, a documented refresh cadence and a stated quality guarantee. Consumers can therefore build on it the way they would build on an API. A raw table with none of those attributes is just storage, and depending on it is how a reporting layer becomes untouchable.

When is a data mesh the wrong model?

When there are not enough domains to federate. Data Mesh Architecture distributes work that a central team was doing, so it needs teams with the capacity to own data engineering alongside their product. With 2 or 3 teams the coordination overhead exceeds the bottleneck it removes, and a well-run warehouse with clear contracts is the better answer.

What does federated governance mean concretely?

Global rules, local implementation. Data Mesh Architecture keeps a small set of standards that everyone must meet — identity conventions, personal-data classification, retention rules — while leaving each domain free to choose its own storage and modelling. That balance is what stops a mesh becoming 12 incompatible islands, and it is the part most often skipped when teams adopt the label without the governance.