Rethinking Data Infrastructure: Optimizing for Data Lakehouses

Image source: “The Data Lake House Is Your Next Cloud Data Warehouse” (Agilisium Blog)

Shifting the Focus to Data Infrastructure

In our previous applications related post, we explored how AI scaling is increasingly limited by memory, not compute, and how technologies like Compute Express Link (CXL) can help address those bottlenecks.

[embed]AI Memory Requirements: Why Memory — Not Compute — is the Bottleneck in AI Scaling AI is fundamentally transforming data center architecture. Training and deploying large language models (LLMs) require…medium.com

For this post, we turn our attention to data lakehouse systems, a modern architecture that combines the strengths of data warehouses and data lakes. We will look at how the lakehouse came about, and how the separation of compute and storage enabled cost efficiency and flexibility but also created new challenges with I/O and data movement.

From Data Warehouses to Data Lakes — and Why Lakehouses Emerged

As noted earlier, the same theme shows up in data infrastructure: the biggest bottlenecks often come from moving and accessing data, not from raw compute power.

For decades, data warehouses were the cornerstone of analytics, evolving into parallel systems that spread work across many servers, allowing them to handle large, structured datasets reliably. Their strength lay in supporting queries for applications like business intelligence(BI), with predictable performance and clear rules for how data was structured and managed, often through strict schema enforcement that required data to fit predefined formats. However, since they were built primarily for structured data such as tables and transactions, they were not well-suited for the messy, high-volume, and diverse data that organizations now collect daily.

As organizations began collecting larger volumes of data from a growing variety of sources, the limitations of warehouses became clear. Companies turned to data lakes — vast, inexpensive repositories of raw data stored in cloud object storage. Data lakes excelled at capturing everything from structured tables to logs, media files, and streaming data. They gave organizations freedom and scale, but they came with trade-offs. Data lakes also became the foundation for new workloads in data science and machine learning, which thrive on access to large, diverse datasets. But without schema enforcement or ways to maintain data quality, lakes often degraded into “data swamps”. Data scientists and engineers could explore the raw material, but analysts and business teams struggled to trust or directly use it.

This gap gave rise to the data lakehouse, an architecture that brings the two approaches together. The lakehouse combines the structure and trustworthiness of a warehouse with the scale and flexibility of a lake, eliminating the need to run two separate systems or constantly move data between them.

The Lakehouse: A Modern Solution

A data lakehouse combines warehouse-like management features with the scalability of low-cost cloud object storage and the efficiency of open file formats designed for analytics at scale. The result is a modern architecture that is cloud-native, able to handle diverse data, and built on open standards.

What sets the lakehouse apart is its ability to combine the strengths of both data lakes and warehouses on a single platform:

• Consistency through transactions and schema enforcement, so multiple pipelines can update data without breaking it.
• Flexibility and scalability to support structured, semi-structured, and unstructured data together, and adapting to both batch and real-time workloads.
• Openness via open formats and APIs, reducing vendor lock-in and making it easy to use different engines, tools, or languages.
• Versatility by handling diverse workloads, from BI dashboards to machine learning pipelines to real-time streaming jobs.

Put simply, a lakehouse is designed to be both reliable and adaptable — a platform that unifies business intelligence, data science, and modern analytics while keeping infrastructure cost-efficient.

Image source: Databricks — “What is a Lakehouse?”

The Ecosystem: Platforms and Formats

Image source: “The History and Evolution of Open Table Formats” by Alireza Sadeghi (Medium)

Since its introduction just a few years ago, the lakehouse has gained wide adoption across the industry, supported by both commercial platforms and open-source projects.

Platforms (full services, application-level)

• Snowflake has popularized the model with its fully managed platform, offering elastic compute clusters and centralized storage, widely used for BI and analytics.
• Databricks, built on Apache Spark, introduced Delta Lake, which brought reliable data management features to cloud storage and enabled both batch and streaming workloads in one system.

Open table/storage formats(underlying building blocks)

• Apache Iceberg, originally developed at Netflix, is designed for petabyte-scale tables and helps manage data that changes shape over time, making it well-suited for long-lived datasets.
• Apache Hudi, created at Uber, focuses on incremental data ingestion and upserts, making it well-suited for real-time data pipelines.
• Delta Lake continues to expand in adoption as a robust open-source storage format that powers many modern analytics workloads.

Image source: “Explaining Data Lakes, Lakehouses, and Catalogs” (Estuary Blog)

Cloud providers have also embraced the lakehouse pattern, with services such as Google BigQuery — and similar offerings from AWS and Azure. The result is a rich and rapidly growing ecosystem of technologies that make the lakehouse architecture accessible to enterprises of all sizes.

Separation and Scaling of Compute and Storage

One of the most important shifts that came alongside the rise of the lakehouse is the separation of compute and storage.

• Storage sits in scalable, low-cost cloud object stores like Amazon S3, Azure Data Lake Storage, or Google Cloud Storage. These systems are highly durable and designed to scale practically without limit.
• Compute, on the other hand, is provided by independent clusters that can be spun up or down depending on workload. This gives teams the flexibility to match resources to the task at hand — scaling up for heavy data processing tasks, scaling down for light reporting queries.

This architecture is cost-efficient because it eliminates the need for overprovisioning — the approach of building monolithic systems with fixed compute and storage sized for peak demand, even if most of that capacity sat idle. Instead, storage grows with data, and compute is elastic. Just as importantly, the separation also allows workload isolation: one team can run large-scale data science experiments without slowing down another team that is generating daily reports.

However, as we noted in the previous discussion of AI memory, separating compute and storage introduces its own challenge: I/O traffic. Every query requires data to be moved across the network from storage to compute. At small scale this may be negligible, but at the scale of modern analytics and AI pipelines, it can become a major bottleneck. That’s why optimizations for reducing network I/O are central to lakehouse performance.

Optimizing Data Movement: Predicate Pushdown and Beyond

To address I/O strain, modern data platforms use several optimization techniques. One of the most effective is predicate pushdown, which means applying filtering conditions as close to the data source as possible. Instead of moving the entire dataset to the compute layer, the storage layer returns only the subset of records that match those conditions. This reduces the amount of data transferred across the network and minimizes what needs to be processed in memory.

Predicate pushdown is supported across many systems — from columnar formats like Parquet and ORC, to query engines like Spark, and table formats such as Delta Lake or Iceberg. In practice, it allows queries to run faster and more efficiently, since less data moves between storage and compute. The benefits compound at scale: lower network traffic, quicker response times, and better utilization of compute resources.

Of course, predicate pushdown is just one technique. Other strategies — such as storing and accessing data in columnar formats, partition pruning, or caching frequently used data — also help reduce I/O, though a full discussion is outside the scope of this post.

Still, as storage servers take on more of this optimization work, their workloads grow heavier. This is precisely where CXL can play a transformative role.

Image source: DZone — “Dynamic Partition Pruning in Spark 3.0”

CXL’s Role in Data Platforms

CXL is not a built-in feature of lakehouse systems, but it is increasingly applicable in this space and offers valuable infrastructure advantages. As compute and storage continue to be separated, optimizations such as predicate pushdown help reduce network traffic — but they also place heavier demands on the storage side, where systems must determine which data is relevant and apply filters before results are returned. Ultimately, the bottleneck comes from the cost of moving large volumes of data back and forth between storage and compute.

CXL helps ease this pressure by introducing large, low-latency memory that sits between compute and storage. Instead of pulling entire datasets from disk storage for each query, active datasets can be kept in CXL-attached memory, allowing filtering and other operations to happen at memory speed. This reduces I/O strain, cuts unnecessary data transfers across the network, and accelerates query performance.

Beyond query filtering, CXL’s flexibility also opens opportunities in related areas such as managing indexing information, improving caching, and supporting mixed workloads that would otherwise contend for limited memory resources. For data lakehouse environments that already depend heavily on these operations, CXL represents a promising way to improve both performance and scalability. For some practical examples of how CXL is being applied, see our previous blog post on CXL use cases.

[embed]CXL Usecase : How far have we come, and what’s next? CXL Usecasemedium.com

Looking Ahead

The evolution from data warehouses to lakes and now lakehouses reflects a broader shift: data platforms must balance flexibility, scale, and reliability while minimizing the cost of data movement. Separating compute from storage has unlocked enormous efficiency, but it also introduced new I/O challenges that can limit performance at scale.

Technologies like CXL offer a path to address these challenges by creating memory-rich layers that sit between compute and storage, reducing unnecessary transfers and enabling faster filtering and analysis. For organizations building on lakehouse architectures, CXL represents not just an incremental improvement but a potential foundation for the next generation of large-scale data infrastructure.

For more information on CXL and how XCENA is advancing this space with our own CXL product, visit our website at xcena.com and follow us on LinkedIn for latest updates.