Few topics in data engineering generate as much tribal energy as lakehouse versus warehouse. Vendors have picked sides, conference talks have picked sides, and somewhere in the noise a genuinely useful architectural question got buried under marketing.
I've built both. I've also migrated between them. And the honest answer to "which should we use?" is the answer most people don't want: it depends — but it depends on a small, knowable set of things. Here's the framework I actually use.
First, drop the false binary
Modern platforms are rarely purely one or the other. A warehouse like Snowflake now reads open table formats; lakehouse engines now offer warehouse-grade governance and performance. The real decision is about centre of gravity: where does the bulk of your data live, and what serves it to the people and systems that need it? Everything else is detail.
The questions that actually decide it
1. What are your workloads, really? If 90% of your consumption is SQL analytics and BI over structured data, a warehouse is a superb centre of gravity — governed, fast, and boringly reliable. If a large share is ML, streaming, or processing of semi-structured and unstructured data at scale, a lakehouse's flexibility and open formats earn their keep.
2. Who's going to operate it? This one is underrated. A warehouse hides an enormous amount of operational complexity — you get performance and concurrency largely for free. A lakehouse gives you more control and lower storage cost, but hands you more knobs to turn. Match the architecture to the team you actually have, not the team on the vendor's slide.
3. How important is open storage? If avoiding lock-in and keeping data in open formats is a genuine strategic requirement — because multiple engines will read it, or because procurement demands it — that pushes toward a lakehouse. If it's a hypothetical worry nobody will act on, don't pay the complexity tax for it.
4. What's the cost profile at your scale? Warehouses are cost-effective until they aren't; separating cheap object storage from compute can win big at very large volumes. But that crossover point is further out than most teams think. Model your actual numbers before optimising for a scale you may never reach.
The trap: architecting for someone else's problem
The most expensive mistakes I see aren't picking the "wrong" option — both are excellent. They're picking an architecture for a problem you don't have. Teams build elaborate lakehouses to avoid lock-in they'd never have acted on, or cram genuinely diverse ML workloads into a pure warehouse because it's familiar. The complexity you add today is paid back with interest for years.
How I actually decide
I start from workloads and team, not from technology. I pick the centre of gravity that serves the majority of consumption with the least operational burden, and I keep the door open at the edges — open formats where they genuinely help, a warehouse serving layer where SQL rules. Pragmatism over purity, every time.
The best architecture is the one your team can run in their sleep while it quietly compounds value. It rarely wins a Twitter argument. It always wins in production.