The distinction between these three has blurred considerably as warehouses learned to handle semi-structured data and lakes acquired transactions. The categories still describe genuinely different starting points and different costs.
Data warehouse
A warehouse stores structured, modelled data optimised for analytical queries. Data is transformed into a defined schema before or shortly after loading, and the engine is built for aggregations across large tables.
Strengths: fast SQL over large datasets, strong governance, mature tooling, and a skill set most analysts already have. Modern cloud warehouses separate storage from compute, so you pay for query time rather than idle capacity.
Limitations: schema changes require migration work, unstructured data fits awkwardly, and costs can escalate quickly with careless querying.
Fits: business intelligence, reporting, dashboards, and any organisation whose analytical needs are mostly SQL over tabular data — which is most organisations.
Data lake
A lake stores raw files in object storage in whatever format they arrived — JSON, CSV, Parquet, images, logs. Structure is applied when the data is read rather than when it is written.
Strengths: very cheap storage, no upfront modelling, handles any data type, and keeps the raw record so a future question can be answered from original data.
Limitations: without discipline it becomes unusable. No schema enforcement means consumers discover breaking changes at query time; no transactions means concurrent writes can produce inconsistent reads; and query performance over unoptimised files is poor.
Fits: machine learning workloads, log and event archives, and situations where data volume makes warehouse storage uneconomic.
Lakehouse
A lakehouse adds a transactional metadata layer over files in object storage, giving schema enforcement, ACID transactions, time travel and efficient updates — warehouse-like behaviour on lake-like storage and cost.
Strengths: one copy of the data serving both analytics and machine learning, open file formats that avoid lock-in, and cheaper storage than a warehouse at scale.
Limitations: more moving parts, a less mature ecosystem than warehouses, and more engineering required to operate well. Query performance for interactive BI generally still trails a dedicated warehouse.
Fits: organisations with both analytics and machine learning needs, large data volumes, and the engineering capacity to run it.
The honest guidance for most teams
Start with a warehouse. It is the fastest path to answering business questions, the tooling is mature, and analysts can use it without engineering support.
Add object storage for raw data you want to keep but do not query often — event streams, logs, exported third-party data. This is effectively a lake used for archive, and it costs very little.
Consider a lakehouse when data volume makes warehouse storage genuinely expensive, when machine learning workloads need the same data as analytics, or when you want to avoid committing to one vendor’s storage format. Not before.
The failure mode worth avoiding is building a sophisticated platform before anyone has asked a question it answers. A warehouse with five well-modelled tables that the business actually uses beats an elegant architecture nobody queries.
ELT rather than ETL
The older pattern extracted data, transformed it elsewhere, and loaded the result. The modern pattern loads raw data first and transforms inside the destination, because cloud warehouse compute is cheap and flexible.
ELT has a practical advantage beyond cost: the raw data is retained, so when a transformation turns out to be wrong you can rebuild from source rather than having lost the original. Transformations defined as version-controlled SQL, tested and scheduled, are considerably easier to maintain than pipeline code.
Governance, which decides whether any of it works
Architecture matters less than whether people can find and trust the data. Four things, none of them technology choices.
- Ownership. Every dataset has a named owner responsible for its correctness.
- Documentation at the column level. What it means, where it came from, how it is calculated. A warehouse nobody can interpret produces confidently wrong analysis.
- Quality tests that run on every refresh. Row counts, null rates, uniqueness, referential integrity. Failures should alert the owner, not surface in a board deck.
- Access control. Row and column level where personal data is involved, which is also what makes a SOC 2 or privacy review straightforward.
Cost control
Warehouse bills surprise people because the pricing model rewards efficiency in ways the old on-premises model did not.
The usual causes of runaway cost: dashboards refreshing every five minutes against full-table scans, transformations rebuilding everything rather than processing increments, analysts running exploratory queries against raw event tables, and warehouses left running because auto-suspend was never configured.
Partition and cluster large tables on the columns people filter by, materialise expensive aggregations rather than recomputing them per dashboard load, and attribute query cost to teams so the spend has an owner.
A sensible first architecture
For a company with no data platform: managed ingestion into a cloud warehouse, transformations as version-controlled SQL, a BI tool on top, and raw exports landing in object storage for archive. That covers the analytical needs of most businesses up to a substantial size, and it can be stood up in weeks rather than quarters.
Add complexity when a specific question cannot be answered by it, not in anticipation.
Modelling, which matters more than the platform
Most of the value in a data platform comes from how the data is modelled, not from which engine runs the query.
A layered approach works well and is widely adopted. A raw layer holds source data untouched, so anything can be rebuilt. A staging layer cleans and standardises — consistent types, deduplicated, renamed to a convention. A marts layer contains business-facing tables modelled around how people actually ask questions: one row per order, per customer, per subscription.
The discipline that pays off is keeping business logic in exactly one place. When “active customer” is defined in four dashboards, four numbers will be reported and the data team will spend its time reconciling them rather than building anything.
Signs the platform is failing
Four symptoms that indicate a problem no architecture change will fix.
Different numbers in different reports. Almost always duplicated business logic rather than a technical fault.
Analysts querying raw tables. Means the modelled layer does not answer their questions, so they route around it — and every such query embeds its own definitions.
Nobody trusts the dashboards. Usually traceable to a few visible errors that were never properly explained. Trust is slow to rebuild and requires visible quality testing.
Every request goes through one person. A bottleneck that looks like a staffing problem and is usually a documentation and access problem.
Frequently asked questions
Can a data lake replace a warehouse?
For machine learning and batch processing, often yes. For interactive business intelligence, a warehouse or lakehouse query engine is usually still required for acceptable performance.
What is a data mesh?
An organisational approach where domain teams own their data as a product, rather than a central team owning everything. It is a governance model, not a technology, and it mainly suits large organisations where central ownership has become a bottleneck.
Do we need a data engineer?
With managed ingestion tools and SQL-based transformation, a capable analyst can run a small platform. A dedicated engineer becomes necessary as source systems, volume and reliability expectations grow.
What about streaming?
Real-time pipelines cost substantially more to build and operate. Most business questions are answered perfectly well by hourly or daily batches. Adopt streaming for the specific use cases that need it rather than as a default.
