Comparison
Data lakevsLakehouse
Data lake
everything anyone might ever need is in a bucket as files, in whatever shape it arrived, and finding the useful part is your problem.
Cheap object storage holding data in open file formats, with no enforced schema at write time. It is the answer to 'we cannot afford to decide yet': you keep everything and interpret it later, which is genuinely valuable when the questions have not been asked. What it does not give you is transactions, consistent multi-file updates or any guarantee that two readers see the same thing, which is the gap the table formats were invented to close.
Full entry →Lakehouse
the tables are open files in a bucket and you still get transactions, schema enforcement and a rollback.
A table format layered over object storage so that a lake behaves like a warehouse: atomic commits, snapshot isolation, schema enforcement and time travel over plain Parquet files. It exists because the two-system arrangement — lake for raw, warehouse for modelled — meant every table was copied, and the copy was the thing that drifted. The remaining trade is maturity: the metadata layer is now a component you operate, and small-file and compaction management is your job rather than the vendor's.
Full entry →