Few debates consume more enterprise data-strategy hours than the architecture question: warehouse, lake, lakehouse, or mesh? Vendors have strong opinions, conference talks have stronger ones, and meanwhile the actual business question — how fast can our organisation turn a question into a governed, trusted answer? — goes unasked.
What actually differs
Strip the marketing and the options differ on three axes: where semi-structured and unstructured data lives, how strictly schema and quality are enforced on the way in versus on the way out, and who owns the pipelines — a central platform team or federated domain teams. A classic warehouse enforces early and centralises; a lake defers everything; a lakehouse enforces at a metadata layer over open storage; a mesh federates ownership regardless of the storage substrate.
Notice that none of these axes is really about technology. They are about your organisation: the ratio of structured to unstructured workloads, the maturity of your domain teams, and how much central governance your industry demands.
A decision rule that works
If your analytical estate is overwhelmingly structured, your teams are lean, and compliance is heavy, a modern warehouse remains the honest answer — boring, governed, fast. If ML workloads over raw and semi-structured data are a first-class citizen, the lakehouse pattern earns its keep: one copy of the data serving BI and ML both, with table formats providing the governance the old lakes lacked. Reach for mesh principles only when the bottleneck is demonstrably organisational — when a central team has become the queue everyone waits in — and even then, adopt the ownership model before the tooling.
The uncomfortable truth is that a mediocre architecture with excellent data quality, clear ownership, and fast pipelines will outperform an elegant architecture without them every single time. Choose the pattern that fits your organisation's shape — then spend your real energy on the fundamentals no pattern can substitute for.