The three architectures, defined plainly
The terms are used loosely enough to be unhelpful, so it is worth being precise.
A data warehouse stores structured, modelled data in a system optimised for SQL analytics — Snowflake, BigQuery, Redshift, Synapse. Data is cleaned and shaped on the way in, and the platform manages storage and compute for you.
A data lake stores raw files in cheap object storage (S3, ADLS, GCS) in any format. It is inexpensive and flexible, and without discipline it becomes a folder of files nobody can query with confidence.
A lakehouse puts a transactional table format — Delta Lake, Apache Iceberg or Hudi — over lake storage, adding ACID transactions, schema enforcement and time travel. Databricks popularised the term; Snowflake, BigQuery and Athena can all now read Iceberg tables, so the boundary is blurring.
What a warehouse is good at
- BI and reporting at speed — sub-second dashboards over modelled tables with minimal tuning.
- A governed semantic layer where a metric is defined once and reused everywhere.
- Fine-grained access control, masking and row-level security that auditors accept without argument.
- A small team can run it. There is no cluster to size, no file layout to think about.
- Mature SQL tooling — dbt, BI tools and ELT vendors all target warehouses first.
What a lakehouse is good at
- Semi-structured and unstructured data — JSON, logs, clickstream, images, audio — without forcing a schema up front.
- Machine learning and data science workloads that want direct file access from Python or Spark, not just SQL.
- Very large volumes where separating cheap storage from burst compute changes the economics materially.
- Streaming and near-real-time ingestion alongside batch, in one place.
- Open table formats, which reduce lock-in: the same Iceberg tables can be read by several engines.
Where they genuinely differ
Marketing claims convergence; in practice the differences that bite are operational.
- Skills: a warehouse needs strong SQL. A lakehouse needs Spark, file-format and partitioning knowledge as well — a real hiring and training cost.
- Governance: warehouse permissions are mature and simple. Lakehouse governance needs a catalog (Unity Catalog, Glue, Polaris) configured properly or it drifts.
- Performance predictability: warehouses tune themselves reasonably well. Lakehouse performance depends on file sizes, partitioning and compaction — small-file problems are a recurring support burden.
- Cost shape: warehouses charge for compute time, usually per second, and idle costs little. Lakehouses split cheap storage from cluster compute, which is efficient at scale but easy to leave running.
- Time to first value: a warehouse plus dbt gets a team to reliable dashboards in weeks. A lakehouse platform built properly takes longer before the first business question is answered.
How to actually choose
Choose from your workloads, not from the architecture diagram you would prefer to have built.
- Mostly relational sources, BI and reporting, a team under ~15 data people: a warehouse with dbt is almost always the right answer, and the cheapest to operate.
- Substantial ML, streaming, or genuinely large volumes of semi-structured data: lakehouse, with warehouse-style modelling still applied to the curated layer.
- Both, in a smaller organisation: start with the warehouse and land raw files in object storage alongside it. That gives you the lake option later without paying for it now.
- Strict residency or sovereignty requirements: check regional availability of the specific managed services first — it eliminates options faster than any feature comparison.
- Hard budget ceiling with spiky workloads: model both against your real query patterns. The answer varies more than vendors admit.
Modelling the cost honestly
Both models are consumption-based, so the bill follows behaviour rather than headcount. The variables that dominate real invoices:
- Query volume and concurrency — dashboards that auto-refresh every minute for 200 users cost real money.
- Warehouse/cluster sizing and idle timeouts. An oversized cluster with a 60-minute idle timeout is the single most common source of waste.
- Data scanned per query. Partitioning and clustering routinely cut a bill by more than half.
- Storage growth and retention — nobody deletes anything unless a policy makes them.
- Egress and cross-region transfer, which is invisible until it is not.
- Pipeline compute: transformations often cost more than the queries they serve.
Modelling matters more than the platform
The most common cause of an unhappy data platform is not the engine choice — it is the absence of a model. Whichever you pick, the same disciplines apply: a raw layer that is never edited, a cleaned and conformed layer, and a presentation layer shaped for consumption (the medallion pattern, or a straightforward dimensional model).
Define metrics once, in version-controlled transformation code, with tests on the assumptions that matter — uniqueness, not-null, referential integrity, freshness. A warehouse with a good model beats a lakehouse without one, every time.
The part nobody budgets for: ownership
Both architectures fail in the same way — not technically, but organisationally. Six months in, nobody can say which of the four "revenue" columns is authoritative, three teams have built parallel pipelines from the same source, and trust in the numbers has quietly collapsed. Rebuilding that trust costs far more than the platform did.
What prevents it is unglamorous and cheap if you start early:
- A named owner per data domain who signs off definitions — not a committee.
- Transformations in version control with code review, exactly like application code.
- Automated tests on the assumptions that matter: uniqueness, not-null, referential integrity, freshness. A failing test should block the pipeline, not send an email nobody reads.
- Column-level lineage, so "where does this number come from" is answerable in seconds rather than by archaeology.
- A documented metric layer that BI tools consume, instead of each dashboard redefining its own logic.
- An agreed retirement process, so old tables actually go away rather than accumulating as ambiguity.
If you already have one and want the other
Migrating between them is a modelling exercise more than a data-movement exercise. Move the data first and prove parity, then move transformations, then move consumers — never all three at once. Run both platforms in parallel for at least one reporting cycle and compare outputs number by number before switching anyone off. Expect the semantic layer, not the storage, to be the long pole.
Frequently asked questions
No. Lakehouse storage is cheaper, but compute is where most of the bill sits, and idle clusters are easy to leave running. At small to moderate scale a warehouse is frequently cheaper overall once you account for the engineering time each one demands.
Not necessarily as a separate system — a lakehouse can serve BI directly. But you still need warehouse-style modelling and a governed semantic layer on top of the curated tables, otherwise every dashboard reinvents its own definition of revenue.
A data lake is files in object storage with no transactional guarantees. A lakehouse adds an open table format (Delta, Iceberg, Hudi) over those files, giving ACID transactions, schema enforcement, updates and deletes, and time travel — the properties that make a lake safe to query.
All four are capable. In practice the decision is driven by your existing cloud, the skills in the team, and whether your workload is SQL-dominant or ML-dominant. Model your real query patterns against each before committing — the cost differences show up in your workload, not in a benchmark.
A first useful iteration — a few source systems, a modelled layer and working dashboards — is typically 8–12 weeks. Treat it as an ongoing capability rather than a project with an end date; sources and definitions change continuously.
Only if your data volumes or workload types demand it. Plenty of organisations run entirely on SQL transformations in a warehouse and never need a Spark cluster. Adopting Spark before you need it adds a permanent skills requirement for no immediate return.
How we can help
Warehouse and lakehouse design, modelling, and ELT pipelines with tests and lineage.
Solution Design & ArchitectureTechnology selection and a costed target state before you commit to a platform.