Lakehouse: Unifying the Data Lake and Warehouse

For a decade, we data teams have lived with an architecture split in two: on one side the data lake, cheap and flexible, where everything lands —logs, files, events, semi-structured data—; on the other, the data warehouse, orderly and fast for business dashboards. It works, but at the cost of duplicating data, maintaining two technology stacks, and moving information back and forth endlessly. At SUMāTO we see more and more companies in LATAM asking whether they really need both. The answer maturing in 2022 has a name: lakehouse.

The short version: The lakehouse is an architecture that puts data warehouse capabilities —transactions, schemas, query performance— directly on top of the cheap, open storage of a data lake. The idea is to have a single place where BI and machine learning coexist, without copying data to a separate system. It is not magic: it is the combination of open table formats and engines that understand them.

The problem with keeping lake and warehouse separate

The two-tier architecture became the de facto standard: you ingest everything into the lake in formats like Parquet and then load a curated subset into the warehouse for the business to query. On paper it is elegant. In practice it generates frictions that pile up.

• Duplication and cost: the same data lives in two places. You pay for storage twice and, more expensively, you pay for the effort of keeping it in sync.
• Stale data: between something arriving at the lake and becoming available in the warehouse, hours or days pass. Dashboards show a snapshot that has already aged.
• Fragile pipelines: each copy process (ETL/ELT) is one more piece that breaks. When it fails, someone gets a call in the middle of the night.
• BI and ML divorced: analysts live in the warehouse with SQL; data scientists live in the lake with Python and Spark. They work on different versions of the truth.
• Fragmented governance: applying permissions, lineage, and quality consistently across two systems with different security models is a permanent headache.

What a lakehouse is

A lakehouse is a data architecture that adds a transactional and metadata-management layer on top of the lake's object storage (for example, cloud storage with Parquet files). That layer turns a heap of loose files into something that behaves like database tables: with schema, with version control, and with reliable transactions.

Put another way: instead of moving the data to the warehouse to obtain its guarantees, you bring the warehouse's guarantees to where the data already is. A single, open repository serves both the leadership dashboard and the purchase-propensity model.

What the lakehouse unifies

The value of the lakehouse is not a single trick, but the sum of three things that historically lived apart.

• Open formats: data is stored in open table formats (like those that have gained traction in recent years: Delta Lake, Apache Iceberg, Apache Hudi) on top of standard columnar files. It is not trapped in a warehouse's proprietary engine; any compatible tool can read it.
• ACID transactions: the table layer brings atomicity and consistency. Multiple concurrent writes and reads do not clash, and a half-finished load does not leave the table corrupted. This is what was missing in the classic lake.
• BI and ML in a single place: the same set of tables feeds SQL queries for dashboards and, at the same time, model training with Spark or Python. There are no two copies and no two truths.

To this are added capabilities once exclusive to the warehouse: schema enforcement and its controlled evolution, and so-called time travel, which lets you query the state of a table at an earlier moment —pure gold for auditing and for reproducing an ML experiment.

Concrete benefits

When the architecture simplifies, the benefits come down to earth fast.

• A single source of truth: fewer copies means fewer discrepancies between what the dashboard says and what the model says.
• Fewer pipelines to maintain: by eliminating the lake-to-warehouse copy stage, there is less fragile code and fewer points of failure.
• Fresher data: analysis works on data close to the moment it is ingested, not on an overnight load.
• More controlled costs: object storage is cheap and is decoupled from compute, which spins up only when needed.
• Unified governance: permissions, quality, and lineage are applied once, over a single set of tables.

For an organization building analytics capabilities and wanting those same data to support AI initiatives, avoiding the fork between BI and ML is perhaps the strongest argument.

When to adopt it (and when not to rush)

The lakehouse is an emerging architecture, not a silver bullet. It is worth considering when:

• You already have a data lake and feel the pain of copying data to the warehouse over and over.
• Your BI and machine learning use cases compete for the same data and today live in separate worlds.
• The volume and variety of data (semi-structured, events, files) weigh down the traditional warehouse.
• You want to avoid vendor lock-in and keep the data in open formats.

It is wise to proceed with caution if your workload is modest and a well-sized warehouse already handles it without friction, or if your team does not yet have maturity operating object storage and distributed engines. The migration is not trivial: it means rethinking ingestion, governance, and consumption tools. The sensible move is usually to start with a bounded domain and grow from there.

Frequently asked questions

Does the lakehouse completely replace the data warehouse?

That is the underlying promise, but in 2022 most organizations coexist with both during the transition. The lakehouse aspires to cover the warehouse's use cases without a separate system; getting there is a journey, not a switch.

Do I need to throw out my current data lake to have a lakehouse?

No. A lakehouse is usually built on the storage you already have, adding an open table layer on top of your files. It is more evolution than replacement.

What sets the lakehouse apart from simply querying the lake with SQL?

Querying the lake directly does not give you reliable transactions, schema control, or consistent performance. The lakehouse's transactional layer is precisely what brings those warehouse guarantees to the files.

Does it work equally well for BI and for machine learning?

That is the point. The same tables feed SQL queries for dashboards and, without copying anything, model training. That convergence is the main reason to look at it.

The first step

Before choosing a table format or an engine, the first step is honest and boring: map where your data architecture hurts today. How many times are the same data copied? How fresh do they reach your dashboards? Do BI and ML work on the same truth? With that diagnosis, deciding whether the lakehouse adds real value stops being a trend and becomes an engineering decision.

At SUMāTO we help organizations across LATAM make that diagnosis and design the path —without leaps into the void. If you want to talk about your case, write to us at sumatogroup.com/contacto.