You are asked to choose between a cloud data warehouse and a lakehouse for a new analytics platform. How do you decide?

What actually differs

The gap has narrowed considerably, so the decision turns on fewer things than the marketing suggests.

Format ownership. In a lakehouse, data sits in your object store in an open format — Iceberg, Delta, Hudi over Parquet — and Spark, Trino, Flink, DuckDB and increasingly the warehouses themselves can all read it. The compute engine becomes replaceable. In a proprietary warehouse, the data is in the vendor's format, and leaving means exporting everything.

Workload breadth. Lakehouses handle non-tabular data, ML training sets and streaming natively. Warehouses are excellent at SQL analytics and progressively less comfortable outside it.

Operational effort. This is the honest counterweight: a warehouse is a managed product where tuning, compaction, small-file handling, catalog management and cluster sizing are somebody else's problem. A lakehouse makes several of them yours, and small-file management in particular is a recurring operational tax that surprises teams.

Cost shape. Lakehouse storage is cheap object storage with compute paid per query or per cluster. Warehouses vary; several now also separate storage and compute, which removes what used to be a clear lakehouse advantage.

How I would decide

Warehouse if the workload is predominantly SQL analytics and BI, the team is small or has no data platform engineering capacity, and time to value matters more than long-run flexibility. It will be faster to stand up and cheaper to operate in people-time.

Lakehouse if there is meaningful ML or streaming, data volumes are large enough that storage cost matters, multiple engines will need the same data, or format independence is a stated strategic requirement.

Both, increasingly, is a legitimate answer: an open table format as the storage layer, with a warehouse engine querying it. Several vendors now support exactly this, and it is the option that keeps the exit cheap while retaining managed convenience.

The question I would ask first

What is the actual workload mix, measured? Teams frequently choose a lakehouse for ML that turns out to be 5% of usage, and then carry the operational cost against 95% BI queries that a warehouse would have served better.

What a strong answer adds

Pricing the exit explicitly for each option, because that is the decision's long tail. "How long would it take to move off this, and what would we have to rewrite?" A lakehouse's answer is usually "point a different engine at the same files"; a proprietary warehouse's answer is a migration project. Whether that difference is worth the operational cost is the real question.