Over the past decade we have moved from rigid data warehouses to flexible data lakes and, more recently, to lakehouse architectures that promise to combine the best of both worlds.
Yet, moving from one generation of data platforms to the next is proving harder than expected. Those already on this journey are uncovering challenges and repeating mistakes by carrying old design patterns into new systems.
Having helped multiple organizations design and scale modern data platforms, I have seen that success depends not on tools, but on discipline. This article is a practical guide, how to transition effectively, what to avoid, and how to translate technical choices into measurable business value.
Why the Pure History of Big Data is no Longer Useful
If we look back, the big data movement began with a dream of unlimited storage and endless experimentation. Around the middle of the 2010s, companies started to collect every possible log, click and transaction, convinced that volume alone would bring insight. In practice, this belief only created more complexity. Data lakes appeared as the fashionable successor to warehouses, yet most of them soon became data swamps, places where information entered easily but rarely came back in a usable form.
By 2022 the industry had matured, and the questions had begun to change. Teams no longer ask how much data they can store, but how they can trust and use what they already have. The real challenge today is not capacity but governance, not ingestion but interpretation.
The key lesson here is simple. Collecting more data does not make a company data driven. What truly matters is understanding the data, maintaining proper governance, and using it efficiently.
I recommend defining ownership for every dataset, setting clear retention and quality policies, and focusing engineering efforts on the data that directly supports business decisions. Without this foundation, even the most advanced lakehouse eventually turns into a modern swamp.
The Lakehouse as a Turning Point
The rise of the lakehouse reflects exactly this shift. Instead of choosing between performance and flexibility, the lakehouse model combines both. At its core, it uses inexpensive cloud storage in formats such as Delta or Iceberg, enriched with metadata and transactional guarantees. The result is a system that costs as little as a lake and behaves like a warehouse when queried.
This is important for business leaders because it removes the constant trade-off between cheap storage for historical data and costly systems for live analytics. I always suggest positioning your lakehouse not as a replacement for everything else, but as a shared foundation that enables both traditional analytics and machine learning in one environment.
In a lakehouse the same environment can support a dashboard for the CFO, a machine learning model that predicts customer behavior, and an ad hoc query from a product analyst. Data is no longer duplicated across systems, which makes governance simpler and allows cost optimization to happen naturally.
Structural and Governance Challenges in Data Lakehouse Adoption
When companies move from classic data warehouses or data lakes to more flexible lakehouse architecture, the transition is rarely smooth. Many teams copy existing structures from the old warehouse into the new environment without rethinking their purpose. The result is the emergence of data silos, in other words, fragmentation. One version of the data lives in the warehouse, another in the lake, and a third somewhere in between. Avoid this by redesigning schemas for the lakehouse from scratch. Model data based on access patterns and consumer needs rather than legacy warehouse logic.
Another recurring issue is normalization. What do I mean by that? Warehouses are built on strict, deeply normalized structures with dozens of interconnected tables. When these are copied directly into a lake, every query requires a forest of joins. Performance collapses, engineers blame the infrastructure, and the project loses credibility. Instead, denormalize where it helps performance and place related entities closer together to minimize shuffle. Treat performance design as part of data modeling, not a later optimization.
Governance and control are critical. In a data lake, there is often little oversight because teams work directly with files. In a warehouse, strict rules apply such as row-level security, role-based access, and detailed audit trails. A lakehouse must strike a balance by ensuring openness without losing accountability. You should implement role-based access and lineage tracking from the very beginning. Governance works best when it grows together with the platform and becomes the foundation of trust.
Performance also depends on smart design. Traditional warehouses rely on automatic indexing, but in lakehouses efficiency comes from partitioning or liquid clustering, caching, and choosing the right file formats for analytics. I recommend treating partitioning strategy and file layout as first-class citizens in your architecture.
Cost optimization is another key promise of the lakehouse, but it doesn’t come automatically. While cloud storage is inexpensive and analytics can scale up or down as needed, these advantages are often offset by poor data design and uncontrolled growth. You must actively manage dataset lifecycles and remove unused copies. If this process is ignored, cloud costs will increase quietly over time.
Cost Optimization as Rule Number One
I’d like to focus in more detail on cost optimization, as it is one of the key advantages of the lakehouse architecture.
One of the key ways the lakehouse architecture reduces costs is by minimizing shuffle, that is, the movement of data between systems or processing nodes. To achieve this, always design your data so that related entities are stored together.
By keeping all data in one place and storing related entities close together, the lakehouse removes the need for excessive joins and data transfers. When we perform analytics, for example when building a machine learning model for customer analysis, we can use both historical and real transactional data without copying or moving it between systems.
Another key principle that enables cost optimization is the decoupling of storage and compute. Data storage and data processing scale independently based on actual demand. We pay only for the resources we use instead of maintaining large fixed-capacity systems. Storage remains inexpensive and scalable, and compute power can be increased or reduced when needed. This flexibility leads to lower infrastructure costs and more efficient data operations. Always start small and let autoscaling do its job. Monitor usage and understand your workload patterns before committing to reserved capacity.
Auto-scaling clusters further help control costs. A machine learning workload needs computing resources in the cloud, virtual machines with memory and processing power similar to a regular computer. In the past, companies bought or leased physical servers in advance and ran processes on that fixed capacity. In the cloud, we pay for compute based on actual usage, per unit of time and per amount of resources. I strongly recommend beginning with minimal cluster sizes, observing scaling behavior, and setting upper limits to prevent runaway costs.
Choosing the Right Architecture Approach
Let’s talk about the lakehouse architecture. In many ways, its design depends on how we structure the data model. The most common and effective approach is the layered, or medallion, architecture, where each layer serves a specific purpose and supports different types of users and workloads.
— The first layer, often called raw or bronze, is a direct copy of the source data. It serves mainly technical needs and is kept only for a short period to allow quick reprocessing when needed. It should be treated as temporary storage.
— The second layer, or normalization layer, contains cleaned and structured data, sometimes joined with other tables like users and orders. This is where machine learning models are often trained. It is best practice to automate data validation and schema enforcement at this stage. Maintaining consistency is more valuable than processing large volumes of data.
— The final layer, known as the gold layer, is where aggregated data lives. Dashboards and BI tools such as Tableau or Power BI typically connect to this layer to access ready metrics and visualizations. Still, not everything can be pre-calculated.
Each layer has a purpose, and together they allow both machine learning and business intelligence to thrive.
You should align your layering strategy with consumption patterns. Data scientists usually work with the silver layer, and executives expect answers from the gold layer. Flexibility is the true strength of the lakehouse, the ability to serve multiple audiences without building and maintaining multiple separate systems.
Insights from the field
If I were designing from scratch, I would do a few things differently from how the industry approached data in the past.
Below are the lessons I’ve learned from real implementations and what I now recommend.
- Start small, deliver fast
Migrating everything at once is not always optimal. Companies often try to lift and shift terabytes of data into a new system, only to find that no one uses it. A better path is to start with a single use case that delivers clear business value, such as a recommendation engine, dynamic pricing, or a customer retention model. Success in that area provides both credibility and a blueprint for scaling.
- Translate business requirements early
I would translate business requirements into technical ones as early as possible. If a report needs to filter by region, that requirement implies partitioning by region at the storage level. If analysts expect near real time updates, that drives decisions about indexing or caching. Without this translation, technology drifts away from business goals and trust erodes.
- Match technology to organizational capability
I would always match technology to the organization’s capabilities. A company with a strong engineering culture may prefer open source components and maximum control. A business with limited technical resources may be better served by managed services that expose SQL interfaces to analysts. There is no universal solution, what matters is aligning ambition with capacity.
Finally, I would challenge the assumption that a lakehouse is simply a better lake. In reality, it is a different paradigm. It inherits some features of both lakes and warehouses, but is not a replacement for every use case. High frequency transactional workloads, for example, may still require specialized systems. Recognizing these boundaries prevents disappointment and ensures that the lakehouse is used where it truly excels.
