Data
Choosing a data platform: warehouse, lakehouse, or both?
08 August 2026
The warehouse-versus-lakehouse debate has generated a lot of strong opinions and, in our experience, most organisations don't actually need to pick a side — they need to be clear about which workload each pattern is solving for.
A data warehouse — Snowflake, BigQuery, or a well-run Redshift — is the right default when the data is primarily structured, the consumers are primarily business analysts and BI tools, and query performance on well-modelled tables matters more than flexibility on raw formats. The cost is that getting semi-structured or unstructured data in usually means an ETL step first.
A lakehouse — Databricks, or object storage plus a table format like Iceberg or Delta Lake — earns its complexity when you genuinely have a mix of structured, semi-structured, and unstructured data, when data science/ML workloads need direct access to raw data rather than a curated warehouse layer, and when storage cost at scale (cheap object storage versus warehouse-native storage) is a real factor.
In practice, the organisations we work with most often end up with both, deliberately: a lakehouse as the landing zone and single source of truth for raw and semi-structured data, feeding a warehouse layer (or warehouse-like semantic layer within the same platform) that's specifically curated for BI and self-service analytics. The mistake isn't picking one — it's picking one and then bolting the other pattern on badly later because the first choice didn't account for a workload that showed up eighteen months in.
The question we ask before recommending either is rarely "warehouse or lakehouse" — it's "what are the three or four consumer workloads this platform actually needs to serve, and in what shape does each of them need the data?" That answer tells you the architecture; the vendor choice comes after.
Frequently asked questions
Is a lakehouse always better than a traditional warehouse?
No. If your data is mostly structured and your consumers are mostly BI/analytics users running well-modelled queries, a warehouse is simpler to run and often performs better for that specific workload.
Can we migrate from a warehouse to a lakehouse later without starting over?
Usually yes, especially if the warehouse data is already reasonably well-modelled - it becomes a curated layer on top of the lakehouse rather than something you throw away. The riskier migration is the reverse: retrofitting lakehouse-style raw data ingestion onto a warehouse-only architecture.
How do we decide which pattern to use for a new project?
Start from the consumers, not the technology. List who queries the data and in what shape (BI dashboards, ad-hoc SQL, ML training data, raw event streams) - that list almost always makes the right architecture obvious.