Data lakehouses try to combine the low cost of a lake with the reliability of a warehouse.
They respond to the cost and drift of keeping the same data in both places.
The key piece is an open table format that sits on top of ordinary files.
The table format keeps a log of which files belong to each version of a table.
Writers add new files and update the log in one step, so readers never see half-finished changes.
That gives reliable updates and deletes, which plain lake files lack.
Old versions stay available, so a query can read a table exactly as it was last month.
The schema is stored and checked, so bad writes are rejected before they land.
Several query engines, such as Spark and SQL engines, can read the same tables.
Storage and computing stay separate, so each can be scaled and paid for on its own.
Small files and old versions pile up, so regular maintenance jobs combine and clean them.
Speed for interactive dashboards can still lag behind a dedicated warehouse in some cases.
Choosing a table format matters, since engines support them to different degrees.
In practice, teams adopt a lakehouse when they need both cheap raw storage and dependable tables.
The usual misconception is that a lakehouse removes the need for careful table design, when tables still need it.