Comparison
Data warehousevsLakehouse
Data warehouse
the data is in typed, governed tables you query in SQL, and getting anything in means agreeing a schema first.
A managed analytical database holding modelled, typed data, optimised for large aggregate queries. You get transactions, a query planner, permissions and predictable performance in exchange for a schema up front and, historically, storage you could not read with anything else. The modern versions blur into the lakehouse, so the meaningful distinction is no longer where bytes live but whether writes are governed and typed.
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 →