Data warehouse vs data lake vs lakehouse is the architecture argument that consumes the most meeting time in mid-sized businesses and produces the least clarity. All three will store your numbers. All three will feed a dashboard. The difference only shows up eighteen months later, in the size of the bill and the number of people it takes to keep the thing running.
The reason the debate goes in circles is that it is usually held as a technology comparison when it is really a comparison of operating models. A warehouse asks you to decide what your data means before you store it. A lake lets you defer that decision, and charges you for the deferral later. A lakehouse tries to give you the second option with the discipline of the first, and mostly succeeds — if your team is ready for it. Framed that way, data warehouse vs data lake is a question about how your business wants to work, not about which product markets itself best.
This guide compares the three on the things that actually move the answer: what each one is and who owns what, how the bill is genuinely built, the governance duties that do not change no matter which you pick, the skills each demands, which workloads belong where, realistic migration paths, and a weighted scoring framework you can complete with your own numbers. Our data warehousing and data management and analytics teams run this decision with UK businesses most months, and if you are costing a reporting programme rather than a platform, the companion guide to Power BI implementation cost covers the budget side in detail.
Table of contents
- Data warehouse vs data lake vs lakehouse: what each one actually is
- Why the data warehouse vs data lake decision stalls in real businesses
- How the bill is really built in a data warehouse vs data lake comparison
- Governance and compliance in a data warehouse vs data lake comparison
- Skills and operating effort in a data warehouse vs data lake decision
- Which workloads belong where in a data warehouse vs data lake split
- The lakehouse in practice: what it fixes and what it does not
- Migration paths for a data warehouse vs data lake move and what they cost
- A weighted scoring framework for your data warehouse vs data lake decision
- Frequently asked questions about data warehouse vs data lake vs lakehouse
- References
Data warehouse vs data lake vs lakehouse: what each one actually is
Strip away the vendor language and the three architectures differ on exactly one axis: when you are forced to agree what the data means. Everything else — cost, tooling, staffing, governance — follows from that single choice, which is why data warehouse vs data lake is a sequencing question before it is a technology one.
The data warehouse: structure first, questions second
A warehouse holds modelled, cleaned, typed tables. Someone has already decided what a customer is, which orders count, and how returns are handled, and the schema enforces those decisions on every load. That upfront work is why a warehouse answers business questions fast and consistently, and why finance trusts it. It is also why adding a new source takes weeks rather than an afternoon, which is the trade at the heart of any data warehouse vs data lake comparison.
The data lake: storage first, structure later
A lake holds files in cheap object storage in whatever shape they arrived — CSV exports, JSON payloads, images, log files, database snapshots. Nothing is validated on the way in, so ingestion is quick and almost anything can land. The cost of that speed is that meaning has to be reconstructed by whoever reads the file, every single time, and two people reading the same folder can produce two different revenue figures without either being wrong. That deferred agreement is the liability side of the data warehouse vs data lake trade.
The lakehouse: one storage layer with warehouse behaviour
A lakehouse keeps the cheap object storage of a lake but adds an open table format — Delta Lake, Apache Iceberg or Apache Hudi — over the files. That layer supplies the things a bare lake lacks: transactions, schema enforcement, time travel, and the ability to update or delete a single row without rewriting a partition. The result behaves enough like a warehouse for BI tools while remaining open to the machine learning workloads a warehouse handles awkwardly, which is why the lakehouse is usually presented as the answer to data warehouse vs data lake rather than a third contestant in it.
Why the three keep getting confused
Because the modern products blur them deliberately. Snowflake reads open table formats, Microsoft Fabric puts a warehouse experience on top of a lake, and BigQuery queries object storage directly. The label on the invoice tells you less every year. What still separates them is the operating model underneath, which is the only part of the data warehouse vs data lake vs lakehouse question worth arguing about.
| Dimension | Data warehouse | Data lake | Lakehouse |
|---|---|---|---|
| Schema decided | On write, enforced | On read, by whoever reads | On write, enforced by the table format |
| Data it accepts | Structured tables only | Anything, including files and media | Anything, with tables governed |
| Typical query users | Analysts, finance, board reporting | Data engineers and scientists | Both, from one copy |
| Storage cost | Higher per terabyte | Lowest per terabyte | Same as a lake |
| Transactions and updates | Native | Not available | Provided by Delta, Iceberg or Hudi |
| Time to first dashboard | Weeks, once modelled | Days to land, weeks to trust | Weeks, similar to a warehouse |
| Skills required | SQL and dimensional modelling | Engineering, Spark, file formats | SQL plus platform engineering |
| Fails when | Requirements change weekly | Nobody owns the definitions | The team is too small to run it |
Why the data warehouse vs data lake decision stalls in real businesses
The technical comparison is the easy part and it is usually settled in an afternoon. What drags a data warehouse vs data lake decision out for months is a set of commercial questions nobody wants to own, and they recur with striking consistency.
The demo dataset is not the production estate
Every evaluation starts with a proof of concept on one clean extract, and every proof of concept succeeds. It succeeds because the hard part — reconciling six systems that disagree about which customer records are live — was excluded from the trial. Judging a data warehouse vs data lake choice on a proof of concept measures the tool’s demo, not your estate, and the gap between them is where the budget goes.
Nobody has priced the transformation work
The platform licence is quoted, agreed and signed. The transformation work that turns raw tables into numbers a director will sign off is neither quoted nor scheduled, because it is nobody’s product. That work is broadly identical in all three architectures, so it should not sway the data warehouse vs data lake decision — but it is usually the single largest line in the first year and its omission makes every option look cheaper than it is.
“Cheap storage” is measured against the wrong bill
Object storage costs a few pounds per terabyte per month, and that figure does a great deal of persuading in lake proposals. It is also close to irrelevant: storage rarely exceeds a tenth of a modern platform bill. Compute and people make up the rest, and a lake shifts effort towards both. Comparing storage prices is the most common analytical error in the whole data warehouse vs data lake vs lakehouse discussion.
The decision is made by the tool the team already knows
If your analysts live in SQL, a lake will be quietly re-implemented as a warehouse within a year, with worse tooling. If your team is Python-first and already running notebooks, a pure warehouse becomes an export-and-ignore layer. Capability is a legitimate input to a data warehouse vs data lake decision — it is just better named openly at the start than discovered eight months in.
How the bill is really built in a data warehouse vs data lake comparison
Every vendor publishes a price list and none of them describes your invoice. In a data warehouse vs data lake comparison the cost models differ in shape more than in total, and knowing the shape is what makes a three-year forecast defensible.
Storage is the smallest line on the invoice
For a business holding a few terabytes, storage is typically the smallest of the three cost lines regardless of architecture. Warehouses charge more per terabyte because the storage is optimised and managed; lakes and lakehouses use ordinary object storage. On realistic mid-market volumes the annual difference is measured in hundreds of pounds, which is not a number that should decide data warehouse vs data lake for anybody.
Compute is the line that surprises everyone
Warehouse compute is billed by the second while a virtual warehouse is awake, so idle clusters and over-eager refresh schedules cost real money. Lake and lakehouse compute is billed by cluster or by bytes scanned, which punishes badly partitioned data hard — a single unfiltered query over an unpartitioned folder can cost more than a week of warehouse time. Both models are controllable, and neither controls itself, so compute discipline matters more than the data warehouse vs data lake label on the platform.
The people cost that never appears in the vendor quote
This is the decisive line. A warehouse needs analysts and a modeller. A lake needs data engineers who understand file layout, compaction and orchestration, and those people are scarcer and more expensive. A lakehouse needs a mix, plus somebody who genuinely understands the table format’s maintenance jobs. Salary and support effort routinely account for more of the three-year total than every cloud invoice combined.
What a realistic first-year budget looks like
Across UK mid-market engagements the split lands in a fairly narrow band, and it is rarely the band that appeared in the business case. The chart below shows where the money actually goes in year one.
| Cost line | Warehouse behaviour | Lake behaviour | What controls it |
|---|---|---|---|
| Storage | Premium per terabyte, managed | Object storage rates | Retention policy and tiering |
| Query compute | Per second while awake | Per cluster hour or bytes scanned | Auto-suspend, partitioning, file size |
| Ingestion | Connector licences and loads | Cheap to land, costly to curate | Number of sources, not volume |
| Maintenance jobs | Largely handled by the platform | Compaction and cleanup you schedule | Table format housekeeping |
| Engineering time | Modelling and SQL | Pipelines, formats, orchestration | Number of pipelines in production |
| Rework | Schema changes ripple downstream | Definitions re-derived per project | Whether anyone owns the definitions |
Governance and compliance in a data warehouse vs data lake comparison
Governance is where the data warehouse vs data lake choice stops being an engineering preference and starts being a board-level risk. The duties are identical in all three; only the amount of work needed to discharge them changes.
Schema enforcement is a governance control, not a technicality
When a schema rejects a malformed load, that is a quality control running automatically. Remove it and the control does not disappear — it moves to a human who may or may not notice. Lakes fail on quality far more often than warehouses, not because the storage is worse, but because the control was deleted and never replaced. A lakehouse restores it, which is the strongest argument in its favour.
Lineage and the audit question
Sooner or later somebody asks where a number came from, usually during an audit or a due diligence exercise. A warehouse can normally answer from its transformation layer. A bare lake usually cannot, because the answer lives in a notebook somebody wrote last year. Lineage tooling exists for all three, but only one of them gives you a usable answer by default, and that difference should carry real weight in a data warehouse vs data lake assessment.
Access control at row and column level
Restricting a column to HR, or rows to one region, is well-trodden in a warehouse and perfectly achievable in a lakehouse through catalogue permissions. In a bare lake it tends to become folder-level permissions, which is coarse enough that people end up with access they should not have. Our guidance on a data governance framework sets out the roles and controls this needs.
UK GDPR duties do not change with the architecture
Storage limitation, data minimisation and the right to erasure apply the same way to a folder of Parquet files as to a warehouse table. The practical difference is effort: deleting one person’s records from a governed table is a statement, while doing it across an unmanaged lake can mean rewriting partitions by hand. Anyone weighing data warehouse vs data lake options with personal data in scope should test erasure before signing anything.
Skills and operating effort in a data warehouse vs data lake decision
Architectures do not run themselves, and the honest version of this comparison is a staffing comparison. This is the factor that most often decides whether a platform is still trusted three years later.
What a warehouse-only team looks like
A small business can run a warehouse with one analytics engineer and a couple of analysts who write SQL. The platform handles storage layout, statistics and most tuning. Growth adds modelling work rather than infrastructure work, and holiday cover is realistic, because the skills are common and the failure modes are well documented. For a lean team this is often the whole data warehouse vs data lake argument in one paragraph.
What a lake or lakehouse team looks like
A lake needs someone who owns file layout, partitioning, compaction, orchestration and schema evolution. That is a genuine platform engineering role, not a task an analyst absorbs. A lakehouse reduces the surface area — the table format handles transactions and much of the housekeeping — but it does not remove the role. If you cannot name the person, the data warehouse vs data lake answer is probably the warehouse.
The on-call reality
Warehouse incidents are usually a failed load or a slow query. Lake incidents are more varied: a partition that grew until queries timed out, small files accumulating until listing costs exploded, a schema change upstream that silently corrupted a column. None is exotic, all need someone who has seen them before.
Which workloads belong where in a data warehouse vs data lake split
Most businesses do not need one architecture. They need to know which workload belongs in which place, and once you ask data warehouse vs data lake per workload rather than per company, the answer is stable across industries.
Finance and board reporting
This belongs in a warehouse or in the governed tables of a lakehouse, without exception. These numbers must reconcile to the ledger, survive an audit and mean the same thing every month. Schema enforcement and a single owned definition are not luxuries here; they are the whole requirement.
Self-service BI for business teams
Also warehouse territory, for a different reason: business users need a semantic layer with well-named, well-typed fields and no opportunity to join two things that should never be joined. A lakehouse serves this well through its catalogue. A bare lake serves it badly, and the symptom is a proliferation of private extracts.
Machine learning and AI feature engineering
Here the lake or lakehouse wins clearly. Model work needs raw history, wide tables, unusual file types and the freedom to reprocess everything after a feature idea changes. Forcing that through a warehouse is expensive and slow. If AI work is on your roadmap, our checklist for AI-ready data covers what these pipelines actually require.
Streaming and near-real-time
Both modern warehouses and lakehouses handle streaming ingestion competently now, so the decision turns on latency targets. Sub-minute freshness with frequent updates favours a lakehouse table format, which was designed for exactly that write pattern. Fifteen-minute freshness is comfortable in either.
Raw archive, images, documents and logs
This is the lake’s home ground and the least controversial part of any data warehouse vs data lake vs lakehouse plan. Object storage is cheap, the data is rarely queried, and none of it belongs in a warehouse. Even organisations that choose a warehouse for everything else usually keep a small archive lake alongside it.
| Workload | Best fit | Why | Acceptable alternative |
|---|---|---|---|
| Statutory and board reporting | Warehouse | Reconciliation and audit trail | Governed lakehouse tables |
| Self-service BI | Warehouse | Semantic layer and typed fields | Lakehouse with a catalogue |
| Machine learning features | Lakehouse | Raw history and reprocessing | Lake plus feature store |
| Documents, images, audio | Lake | Non-tabular by nature | Lakehouse storage layer |
| Event and clickstream data | Lakehouse | Volume with query discipline | Warehouse if volumes are modest |
| Long-term archive | Lake | Lowest cost per terabyte | Cold tier of any object storage |
| Operational dashboards | Warehouse | Predictable, tuned performance | Lakehouse with cached tables |
The lakehouse in practice: what it fixes and what it does not
The lakehouse is now the default recommendation in most vendor material, which is reason enough to look at it sceptically. It solves a real problem, and it introduces a real obligation.
What the table format actually gives you
Delta Lake, Iceberg and Hudi all add a metadata layer over your files that tracks which files belong to a table at which version. From that one idea you get atomic writes, consistent reads while a job is running, row-level updates and deletes, schema enforcement and the ability to query the table as it stood last Tuesday. Those are the warehouse features people miss most in a lake.
Where the lakehouse genuinely wins
One copy of the data serving both BI and machine learning is a substantial saving, and not only in storage. It removes an entire class of arguments about which copy is authoritative, and it removes the pipeline that kept the second copy in step. For businesses doing serious analytical and AI work at once, that consolidation is the strongest case in the whole data warehouse vs data lake vs lakehouse comparison.
Where it still loses to a warehouse
For pure BI on modest volumes with a small team, a managed warehouse remains simpler, cheaper to operate and easier to hire for. The lakehouse asks you to own maintenance jobs — compaction, vacuuming, statistics — that a warehouse hides. A five-person IT function running twelve dashboards does not need that responsibility, and handing it over is the most common and expensive way to get data warehouse vs data lake wrong.
The maturity question
The formats are production-grade and widely adopted; the gap is organisational. A lakehouse rewards teams with version control, testing and deployment discipline already in place, and punishes teams without them. Assess your engineering practice honestly before assuming the architecture will supply the discipline your process does not have.
Migration paths for a data warehouse vs data lake move and what they cost
Almost nobody starts from nothing. The realistic question is which path takes you from what you have to something defensible, and each has a distinct failure mode.
Warehouse first, lake later
Model the reporting core, get finance onto trusted numbers, then add object storage for archive and machine learning once someone actually needs it. This is the lowest-risk sequence for a business whose main pain is inconsistent reporting, and it is the most common recommendation we make in a data warehouse vs data lake engagement. The failure mode is a lake bolted on years later with no owner.
Lake first, warehouse on top
Land everything cheaply, then build serving tables for BI once patterns emerge. Attractive when sources are numerous and requirements genuinely unknown. The failure mode is well documented: the serving layer never gets built, the lake becomes a swamp, and analysts quietly rebuild extracts in spreadsheets while the platform sits unused.
Straight to a lakehouse
Viable, increasingly common, and the right answer when you have real engineering capability and both BI and AI workloads from day one. The failure mode is a team that adopted the architecture for its roadmap rather than its requirements and cannot keep up with the maintenance jobs it inherited.
The path most UK mid-market businesses actually take
A pragmatic hybrid: a warehouse or governed lakehouse for the numbers the business reports on, an archive lake for everything else, and one platform rather than two. The chart below shows how long each route typically takes to reach a first trusted, reconciled dashboard.
A weighted scoring framework for your data warehouse vs data lake decision
Opinions repeat until somebody scores them. Rate each criterion from one to five for each architecture, multiply by the weight your business genuinely warrants, and the argument usually resolves in a single session.
The seven criteria that move the answer
Reporting trust, AI and machine learning ambition, data variety, in-house engineering capability, three-year total cost, compliance exposure and speed to first value. Nothing else has repeatedly changed an outcome in our engagements, and adding criteria mostly dilutes the ones that matter.
How to weight them for your business
A business whose pain is finance reporting weights trust and compliance heavily, and the warehouse wins on arithmetic rather than on advocacy. A business building products on its own data weights variety and AI ambition, and the lakehouse wins. If capability scores low, discount every option that needs a platform engineer you do not employ and cannot recruit within the timeline.
Reading the score honestly
If two options land within about ten per cent of each other, they are tied and you should pick the one your team can operate on a bad week. A large gap is worth trusting. The value of the exercise is not the total — it is that everyone finally sees which criterion drove the data warehouse vs data lake outcome, and can challenge that one criterion instead of the conclusion.
| Criterion | Typical weight | Favours warehouse when | Favours lakehouse when |
|---|---|---|---|
| Reporting trust | High | Numbers must reconcile monthly | Governed tables are already in place |
| AI ambition | High | Analytics only, no model work | Models need raw history |
| Data variety | Medium | Everything arrives as tables | Documents, events and media |
| Engineering capability | High | SQL skills, no platform engineer | Named owner for the platform |
| Three-year cost | Medium | Volumes stay in low terabytes | Volumes grow fast and unevenly |
| Compliance exposure | High | Heavy personal data duties | Catalogue and lineage in place |
| Speed to first value | Medium | A board deadline this quarter | Timeline measured in quarters |
Frequently asked questions about data warehouse vs data lake vs lakehouse
Can we run a data lake and a warehouse together?
Yes, and most mid-sized businesses end up doing exactly that. The lake takes raw and archive data, the warehouse serves reporting. Treating data warehouse vs data lake as an either-or is the mistake; the one rule worth enforcing is that a single owned definition of each metric lives in one place, so the two never disagree about revenue.
Is a lakehouse always cheaper than a warehouse?
No. It is usually cheaper on storage and often on compute at scale, and frequently more expensive on people. Below roughly ten terabytes with a small team, a managed warehouse commonly wins on total cost once salaries are counted honestly.
Does Microsoft Fabric settle the data warehouse vs data lake question?
It narrows it. Fabric presents a warehouse experience and a lakehouse experience over one storage layer, which removes the copying problem. You still choose which experience each workload uses, and that choice is the same decision with different labels.
What is a data swamp and how do we avoid one?
A swamp is a lake nobody can find anything in, because ingestion was funded and cataloguing was not. Avoid it by requiring an owner, a catalogue entry and a retention rule for every dataset before it lands, not afterwards.
How much data do we need before a lake makes sense?
Volume is the wrong trigger. Variety and reprocessing needs are the right ones: if everything you hold is tabular and queried the same way each month, a warehouse suffices at any size. If you are storing documents, events or media for future analysis, a lake earns its place at a fraction of that volume.
Do we need to decide this before starting a BI project?
Decide the serving layer, not the whole estate. You can begin a reporting programme against a warehouse or governed lakehouse tables and defer the rest, provided the definitions are owned. Our data analytics team usually sequences it that way.
