Comparison
LakehousevsStorage-compute separation
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 →Storage-compute separation
you scale up the query cluster for the month-end run and the data does not move anywhere.
Keeping data in shared storage that any amount of independently scaled compute can read. It is the architectural change that made elastic warehousing possible: compute can be sized per workload, several workloads can read the same table without copies, and storage is billed at object-storage rates. The cost is that every read crosses a network, which is why local caching, file layout and pruning matter so much more than they did on tightly coupled systems.
Full entry →