The traditional two-tier architecture
To understand how we got here, we have to look back a few years at the traditional two-tier architecture that became the industry standard for big data:
Data lake – A cheap and highly horizontally scalable storage repository. It supports unstructured, semi-structured, and structured data, which means it can store a variety of file types like CSV, Parquet, Avro, JSON, and many more. Default Data lakes are Schema-on-read, so they don’t require defining a specific schema when loading the data.
Data Lake can have many different data sources:
- Transactional & Operational Databases
- IoT Data
- SaaS & Third-Party APIs
- Media & Files
Analytical database (in most cases data warehouse) – This one focuses on performance. Data moved from a data lake must be optimized for fast querying and business intelligence (BI) workloads. Unlike the data lake, a data warehouse enforces a strict structure known as schema-on-write. This means data must be carefully cleaned and transformed before it can be loaded. While this guarantees high data quality and blazing-fast SQL performance, it comes with steep downsides: compute can be expensive, and the rigid structure makes it hard to adapt quickly to new business needs.
Although data lakes offer immense flexibility and cheap storage, they lack the underlying structure needed for high-performance analytical queries. Conversely, data warehouses are fast and reliable but are strictly confined to structured data and require extensive ETL pipelines to ingest anything else.
This brings us to the biggest challenge in this classic setup: the friction of moving data between the two tiers. Data engineers must build and maintain complex, brittle ETL (Extract, Transform, Load) pipelines to constantly sync the lake and the warehouse. As the scale of data and the number of sources grow, managing these pipelines becomes exponentially harder, eventually turning the central data team into a massive organizational bottleneck. This often results in delayed data and frustrated business stakeholders.
While modern cloud warehouses have recently tried to bridge this gap with federated queries and external tables, for years this rigid separation was the harsh reality for data teams – and for many companies running standard architectures, it still is.
Implementing the lakehouse
The answer to the two-tier architecture problems in Data Engineering was the Data Lakehouse. It is a fairly new architecture, or in other words, a data management pattern that, in theory, solves most of the friction of the two-tier setup. But how exactly does a Data Lakehouse work?
At its core, a Data Lakehouse doesn't replace your Data Lake; it builds directly on top of it. The cheap, horizontally scalable object storage remains the foundation.
The first step in the upgrade is standardizing the raw data into optimized, open file formats like Apache Parquet or Apache Avro. Parquet stores data in a columnar format, which is vastly more efficient for analytical queries than row-based formats like CSV or JSON. On the other hand, Avro, a row-oriented format, works best with high-frequency streaming data or CDC ingestion.
However, the real magic happens in the next layer, the metadata. By introducing open table formats like Apache Iceberg, Delta Lake, or Apache Hudi, the Lakehouse creates a smart metadata layer that sits right above your files. Instead of a compute engine blindly scanning millions of files in the lake, it reads this metadata layer first. What is more, it adds ACID transactions support, so the ability to safely update, delete, and insert records concurrently without the risk of data corruption.
Data Lakehouse can be implemented in many different variations available in the market and as part of open source distributions. It supports many powerful engines like Spark, Trino, or Flink. For a small to mid-sized organization, this unified infrastructure is often the ultimate destination, empowering a single data team to efficiently handle all of the company's analytics without the nightmare of syncing disparate systems.
The breaking point: When Data Lakehouse is no longer enough
Let’s create a scenario. You work in a small game studio. Your last game was a global hit that brought millions of players. The company quickly jumped from processing and storing terabytes of data monthly to terabytes hourly. You’ve upgraded to a Lakehouse, which perfectly solved problems with storage costs and pipeline sync issues.
However, moving from a mid-size to an enterprise means the company now has many new departments: Marketing, Sales, Monetization, Security, Anti-Cheat. Every minute, these departments generate complex data that needs to be processed, modeled, and served. But there is still only one central Data Engineering team that handles it all.
This is where context loss occurs.
Central data engineers are infrastructure experts, but they often lack the understanding of specific logic of a given domain. For example, a data engineer might be asked to improve some specific data process in finance, but this could be difficult without experience in this field, so it requires onboarding. This process of moving information between business and engineering teams in most cases will extend implementation time.
The central team can quickly become overwhelmed by an unmanageable backlog of ad-hoc requests, constantly acting as a middleman to understand the data they are supposed to be modeling. At the same time departments that are waiting for the data need to designate people to provide onboarding and training sessions for engineers where in fact they could focus on other tasks. Organizations often need stronger data engineering capabilities, from platform design and pipeline development to governance and scalable data delivery.
Another problem is access management and unclear ownership. Again, if something is wrong with a specific data source, all eyes are looking at one central team. Even if a dataset hasn't been maintained for years (or worse, was built by an engineer who has since left the company) the central team still gets blamed when it breaks. What follows after that is the danger of a data swamp. Data Lakehouses do provide ACID, and a nice data structure, but that does not prevent users from loading data that is later unsupported and unsupervised.
At this scale, the realization hits: you can't solve all these problems by just buying faster compute. The Lakehouse infrastructure isn't failing; the organizational chart is failing. When the bottleneck shifts from technology to people, a pure infrastructure upgrade is no longer enough. You need a shift in governance and architecture, which can be solved in many ways, and one of them is Data Mesh architecture.
Adopting the Data Mesh
Data Mesh is a Socio-Technical decentralized architecture designed by Zhamak Dehghani. It is built on four pillars:
Domain ownership
Data is managed by the team that is the closest to the source of it. This means the people modeling the data are the ones who understand it best, making the business domain the true owner of its data. Another benefit is that the central Data Engineering team no longer needs to handle modeling and serving of data from all departments because this is the domain's job. All domains provide end-to-end ownership of their data.
Data as a Product
In Data Mesh, the concept of sharing information between domains comes down to the creation of Data Products. They are self-contained, discoverable, and highly trustworthy data assets. Instead of just dumping raw logs into a central bucket, the domain team provides clean, documented data with clear schemas, quality metrics, and access controls, effectively treating other departments as their "customers."
Self-serve Data Platform
The Data Engineering team that previously managed everything related to data can focus now on providing a stable and reliable platform across all domain teams. The task is to build the whole infrastructure with monitoring, policy automation, and testing that allows Domain teams to quickly develop Data Products and share them across the whole organization. This platform can be based on many data management concepts, and one of them is the Data Lakehouse. In this scenario, the centralized Data Engineering team no longer acts as a bottleneck for data modeling, but it still supports domains with the platform creation and complex infrastructural tasks.
Federated Computational Governance
Because data is now distributed across multiple domains, you cannot rely on a single central gatekeeper for security. Federated Computational Governance means setting global standards – like data privacy rules (GDPR), encryption standards, and interoperability protocols – but automating their enforcement through code. The self-serve platform automatically applies these rules, ensuring that while domains have the freedom to build, they can't break compliance.
Returning to our game studio, these four pillars create a highly scalable architecture that should remove engineering bottlenecks for the centralized team. It solves the ownership issue, as now teams are split into domains with a clear hierarchy. When the Monetization or Marketing team needs clean player telemetry, they can search for and request a Data Product directly from the Anti-Cheat domain without needing a central engineer as a middleman. Because the domain owners are the actual experts in their field, they can immediately answer questions, fix data issues, or update logic themselves.
Most importantly, the underlying technology doesn't get thrown away – the studio's Data Lakehouse still exists as the technical foundation, while the Data Mesh operating model ensures the organization can scale with a culture where data is trusted and accessible.
Data Lakehouse vs Data Mesh: Which approach do you need?
Ultimately, comparing a Data Lakehouse to a Data Mesh misses the point entirely. The Data Lakehouse is a powerful infrastructure upgrade that fixes the costly, fragile divide between traditional lakes and warehouses. For the vast majority of small and mid-sized organizations, a centralized Lakehouse is all you need.
However, when hyper-growth hits, faster compute won't save you from a bottlenecked engineering team. That is where Data Mesh takes over. Just remember that Data Mesh is not a silver bullet. Decentralizing too early without technical talent inside your business domains will simply trade a central bottleneck for decentralized chaos. Let your pain points guide your architecture: use a Data Lakehouse to scale your technology, and adopt a Data Mesh only when you need to scale your people.
