Data lake vs lakehouse

Both store data cheaply in object storage. A data lake keeps files as they are; a lakehouse adds an open table format on top, giving those files database guarantees: transactions, schemas, updates and fast SQL.

At a glance

	Data lake	Lakehouse
Storage	Files in object storage	Files in object storage plus a transaction log
Schema	Applied on read	Enforced on write, can evolve
Transactions	None: partial writes possible	ACID transactions
Updates and deletes	Rewrite files manually	Supported at row level
BI and SQL performance	Slow to moderate	Good, approaching a warehouse
Data science and ML	Good	Good
Governance	Depends on external catalog	Built into table metadata and catalog
Operational work	Low, but quality suffers	Table maintenance required

Choose a data lake when

You mainly need cheap, long-term retention of raw data.
Consumers are data scientists processing files in batch.
You don’t need reliable updates, deletes or concurrent writes.

Choose a lakehouse when

The same data must serve both BI dashboards and machine learning.
You need to update or delete records, for example for privacy requests.
You want warehouse-like reliability without proprietary storage.

The verdict

For new analytics platforms, a lakehouse is usually the better default: it costs little more than a lake and avoids the data-quality problems plain lakes are known for. Keep a plain lake only for raw archival zones where transactions and fast queries don’t matter.

Read more

Written and edited by Abhinav Taduka, enterprise software architect.