Lakehouse or warehouse: choosing on workload rather than on fashion

The lakehouse-versus-warehouse question generates more vendor content than almost any other in data architecture, most of it written by people selling one or the other. The honest answer is that it depends on workload — and the workload profile that favours each is reasonably clear.

When a cloud warehouse wins

Structured data, a BI-dominant consumption pattern, moderate scale, a team fluent in SQL and not in Spark, and no near-term ambition for machine learning or unstructured data. A cloud warehouse in this profile is simpler to operate, easier to staff, and often cheaper. Adding a lakehouse here is complexity without return.

When a lakehouse wins

Substantial unstructured or semi-structured data, data science and machine learning as first-class workloads, very large scale, or a need to serve AI systems that consume documents as well as tables. The lakehouse's ability to govern files and tables under one catalogue, and to support both SQL and programmatic workloads, is decisive here. Trying to serve this profile from a warehouse leads to a shadow data lake growing beside it.

The cost profile nobody mentions

Warehouse pricing is easy to model and easy to overrun through uncontrolled query patterns. Lakehouse pricing is harder to model and easier to control through workload isolation — but requires engineering discipline the organisation may not yet have. Either can be expensive; they are expensive in different ways, and the way that suits your organisation depends on who will be operating it.

Our usual advice

If AI is genuinely on the roadmap, a lakehouse is the more durable foundation. If it is not, resist being sold one. And whichever you choose, the semantic layer, governance and pipeline discipline matter more than the platform beneath them.