Gartner’s 2022 Hype Cycle predicted that data mesh would become “obsolete before plateau.” Three years later, that assessment looks prescient but incomplete. The problem wasn’t the concept itself. Data mesh offered genuinely useful ideas about domain ownership, product thinking, and distributed responsibility.
The problem was the reality of implementation.
Data mesh isn’t a techology, it’s an idea
Data mesh isn’t software you buy and deploy. It’s an organizational restructuring paradigm. That matters because implementing a technology is one thing, but implementing an organizational principle often requires capabilities most companies don’t have:
- Distributed data engineering talent
- Mature DevOps practices
- Domain teams ready to own the infrastructure they’ve never managed before
- The organizational patience to see a multi-year transformation through.
Looking back at data mesh today, it’s important to consider it in this light. With that in mind, this post will unpack data mesh as it stands today, and assess its core features, while considering whether any parts of it are actually commonly in production today.
What is data mesh?
When Zhamak Dehghani introduced the concept of data mesh in 2019, she proposed four foundational principles that challenged conventional wisdom. Let’s start there.
Domain-oriented ownership
Business domains manage their own data instead of handing it off to a central team. Marketing owns marketing data. Sales owns sales data. Each domain becomes responsible for the quality, availability, and documentation of what they produce.
Data as a product
Domains treat their data outputs like products with quality standards, documentation, SLAs, and user feedback loops. This means thinking about downstream consumers, maintaining backward compatibility, and investing in usability. Modern data platforms help enforce these product standards through built-in governance and quality controls.
Self-serve data infrastructure
Teams provision what they need without waiting for central IT. Infrastructure-as-code, automated deployments, and platform abstractions let domain teams move fast without becoming infrastructure experts. Self-service analytics platforms can provide this capability while maintaining necessary governance controls.
Federated computational governance
Standards are set centrally but executed locally by domains. Privacy rules, security policies, and compliance requirements get enforced through automation, not manual review of every pipeline. Federated access control ensures domains can operate independently while meeting enterprise standards.
These principles resonated because they addressed real pain. Every data leader knows the frustration of a six-week backlog for simple data pipeline changes. Every analyst has rebuilt the same customer metric because they couldn’t find or trust what another team built. Every executive has asked why insights take so long when the data already exists.
Where data mesh stands today
Data mesh isn’t dead, but it’s also not the revolution some predicted. The concept introduced valuable ideas that are getting adopted selectively, often without the “data mesh” label attached.
Centralized architectures create demonstrable bottlenecks as data scale grows. Domain teams genuinely understand their data better than central teams can. Treating data like a product measurably improves quality and usability. Self-service platforms reduce time-to-value. Those insights stick even when full mesh implementations don’t.
The question for data platform leaders has shifted from “should we do data mesh?” to “which parts of data mesh solve our actual problems?” Understanding both the benefits and the challenges helps make that assessment. That’s less exciting than revolutionary transformation, but far more useful for organizations trying to improve their data operations.
Where implementations break down
Teams implementing data mesh repeatedly encounter the same problems, and these aren’t edge cases. They’re fundamental challenges that emerge from the architecture itself.
There are a few things to consider.
Ownership boundaries get messy fast. When domains overlap, or data gets used across multiple teams, the question of who owns what becomes an ongoing negotiation, not a clean architectural paradigm. The marketing team’s customer data feeds the sales pipeline, which feeds finance forecasts, which feed executive dashboards, which inform product strategy. Where does one domain end and another begin? Is the customer a marketing domain concept or a sales domain concept? What about when finance needs to reconcile revenue attribution across both?
The talent gap is structural, not temporary. Data mesh needs data engineers, product managers, and analysts embedded in every domain. Most organizations don’t have that bench depth, and hiring doesn’t solve it. You can’t just tell a marketing team to “own their data” when they’ve never managed infrastructure, debugged failing pipelines, or optimized query performance. The learning curve is measured in years, not quarters.
Catalogs become graveyards without constant curation. Data products need to be discoverable, usually through a data catalog. But catalogs require relentless maintenance that competes with feature work. Search for “revenue” and get 200 results, many of which are outdated, some contradictory. The mesh stops working. Outdated documentation is worse than no documentation because it erodes trust. Automated data discovery and cataloging can reduce this maintenance burden significantly.
Quality standards diverge without strong enforcement. Without robust federated governance, each domain picks its own tools, formats, naming conventions, and quality thresholds. What was supposed to break down data silos creates new ones. The marketing domain uses Airflow and Parquet. Sales uses custom Python scripts and CSV exports. Finance demands SQL Server compatibility. Product analytics runs everything in Databricks notebooks.
The decentralization that should bring agility ends up causing fragmentation instead. Integrating data across domains becomes harder, not easier. You end up with the same integration problems you had before, except now they’re distributed, and there’s no central team with authority to set standards.
Platform complexity grows faster than platform capability. Self-service platforms sound simple in principle. Essentially, it amounts to giving teams the tools to help themselves. In practice, building a platform that’s both powerful enough for advanced users and simple enough for domain experts requires enormous investment. You need infrastructure automation, security controls, cost management, monitoring, alerting, documentation, training, and ongoing support.
Many organizations underestimate this. They build a minimal platform, declare victory, then watch it collapse under the weight of exceptions, special requests, and teams working around limitations. The platform becomes another bottleneck, just distributed across tools instead of people.
What works about data mesh today
Despite these challenges, some organizations are making data mesh principles work. But they’re selective about what they adopt and realistic about timelines.
Large enterprises with distributed operations see the most success. Organizations that already operate through independent business units have a structural advantage. The Department of Defense uses data mesh concepts to coordinate across entities with genuine operational independence. Financial institutions with multiple product lines—retail banking, commercial lending, wealth management—use domain ownership to accelerate analytics without imposing artificial centralization.
These organizations already had distributed teams and mature data practices before starting. They didn’t need to create a domain structure; they needed to connect domains that already existed. Modern data platforms like Starburst help bridge these distributed environments with query federation capabilities that let domains maintain ownership while enabling cross-domain analytics. For organizations with multi-cloud or hybrid architectures, this federation becomes even more critical.
Incremental adoption beats big-bang transformations every time. Companies that succeed start by building self-service platform capabilities first. Once teams can provision infrastructure without submitting tickets to central IT, they introduce domain ownership gradually. Pilot with two domains that have clear boundaries, strong data engineering talent, and real problems that ownership could solve. Learn what breaks. Fix it. Expand slowly over quarters or years, not weeks.
This approach limits the blast radius when things go wrong. If your marketing and sales pilot fails, you haven’t disrupted the entire data organization. You can roll back, adjust, and try again. Organizations that announced “we’re doing data mesh” and restructured everything simultaneously often found themselves with neither the benefits of decentralization nor the clarity of centralized control.
Platform-as-a-product is the most transferable piece. Even organizations that skip full data mesh benefit enormously from treating their data platform as a product with users, feature requests, quality standards, and a product roadmap. This works whether governance stays centralized or goes federated. Data product portals help teams discover, understand, and access data products across the organization.
Platform-as-product thinking means actually talking to data consumers, measuring platform adoption and satisfaction, deprecating unused features, and investing in developer experience. It means having a team that says, “our job is to make data teams successful” instead of “our job is to run infrastructure.” That mindset shift delivers value regardless of organizational structure.
For organizations looking to implement self-service analytics without full mesh complexity, unified analytics platforms provide a practical middle ground by offering query federation and access control while maintaining centralized platform management.
Treating data as a product improves outcomes even in centralized models. Product thinking—defining SLAs, maintaining documentation, versioning changes, and soliciting user feedback—makes data more valuable whether it’s owned by domains or central teams. The mechanics of product management apply to data regardless of who manages it.
What about data fabric?
While data mesh captured attention with its organizational revolution, data fabric took a different approach: solving similar problems through technology rather than restructuring. Understanding the distinction matters because they’re often confused or treated as competing alternatives when they can actually complement each other.
What is data fabric?
Data fabric is an architectural pattern, not an organizational model. Where data mesh prescribes who owns data and how teams operate, data fabric focuses on how data gets integrated, accessed, and managed across distributed environments. It uses automation, metadata management, and integration technologies to create what feels like unified access to distributed data sources.
The core idea: rather than moving data into centralized repositories or forcing teams to adopt domain ownership, data fabric creates an intelligent integration layer. Active metadata, semantic layers, and knowledge graphs help users find and access data wherever it lives. Technologies like Trino enable this by providing distributed SQL query engines that federate across multiple data sources without requiring data movement.
Many successful implementations combine both. Domain ownership from data mesh paired with technical integration from data fabric creates the best of both models. Domains treat their data as products with clear ownership and quality standards. Data fabric handles discovery, lineage, and cross-domain queries. The fabric doesn’t eliminate the need for domain responsibility, but it dramatically reduces the technical complexity of connecting domains. Open data lakehouse architectures enable this hybrid approach by combining storage flexibility with query federation.
Platforms like Starburst Galaxy exemplify this hybrid approach, offering both the federation capabilities central to data fabric and the access controls necessary for data mesh domain boundaries. Organizations can implement domain ownership while still providing unified query access across those domains.
The choice depends on your actual problems. If your primary pain is central team bottlenecks and unclear ownership, data mesh principles (especially domain ownership and data-as-product) address that directly. If your primary pain is integrating data across distributed systems with complex access control, data fabric technologies provide proven solutions. If you have both problems—and many organizations do—you need elements of both.
Practical guidance for 2025
If you’re evaluating data mesh or data fabric concepts in 2025, focus on matching solutions to actual problems rather than adopting frameworks wholesale.
Assess your organizational maturity honestly. Do you have domain-oriented teams that could realistically own data? Data engineering talent distributed across those teams, not just in a central function? Executive support for a multi-year transformation with inevitable setbacks? CI/CD practices and infrastructure-as-code already in production use? If not, fix those gaps first. Data mesh will fail without them, and data fabric will be underutilized.
Build platform capabilities before pursuing decentralization. Self-service infrastructure, data catalogs, automated deployment pipelines, quality monitoring, and observability are useful regardless of your governance model. Get those working reliably. Then decide if decentralization makes sense.
Start with two pilot domains, maximum. Pick teams with clear boundaries, strong data engineering capability, and real problems that domain ownership could solve. Give them genuine autonomy—if you’re second-guessing every decision, you’re not really testing data mesh. See what breaks: catalog maintenance, cross-domain queries, quality standards, access control, and cost management. Fix those problems systematically before expanding.
Invest in federation technology if you need cross-domain analytics. If your domains need to stay independent but your users need unified access, federation becomes critical. Modern query engines can query across domains without centralizing data, but they require investment in metadata management, security integration, and performance optimization. Don’t assume federation is simple just because it’s technically possible.
Organizations that skip this investment end up with domains that work fine independently but can’t support cross-domain use cases. That undermines the mesh value proposition and creates pressure to recentralize.
Set realistic timelines and measure actual outcomes. Data mesh implementations take years, not quarters. You need sustained executive commitment, ongoing training investment, and organizational tolerance for learning through failure. Quick wins come from self-service platform capabilities and product thinking, not full mesh implementations.
Know when to stop or pivot. Not every organization needs a data mesh or a data fabric. If centralized data teams work well, domain boundaries are genuinely unclear, or you lack distributed talent, don’t force decentralization. If your integration challenges are simple or your data sources are already consolidated, you might not need fabric architecture. The goal is better data operations, not architectural purity or buzzword compliance.
