If most of what you collect arrives from operational databases and SaaS APIs with a schema you can name, buy a warehouse and stop. A data lake earns its place when you hold payloads whose shape you cannot fix, or when your volume makes warehouse-managed storage uncomfortable. The lakehouse is the right answer only when one copy of the data has to be served to more than one compute engine.
The three are usually presented as an evolution, as though the lakehouse supersedes the other two. It does not. They are three different trade-offs between storage cost, governance and the amount of engineering you have to fund forever.
What the three actually are
A data warehouse holds tables with an enforced schema, its own storage, and its own SQL engine. You commit the shape of the data on write, and in exchange you get transactions, row-level permissions and predictable query performance under concurrency.
A data lake is files in object storage. Parquet, JSON, CSV, PDFs, audio. Schema is interpreted at read time, storage is cheap per terabyte, and nothing enforces correctness.
A lakehouse is a lake plus an open table format layered over those files. The table format adds a metadata log, which buys atomic writes, schema evolution, row-level deletes and point-in-time reads, while the bytes stay in your own object storage and any engine that understands the format can read them.
The cost lines that differ
| Cost line | Warehouse | Lake | Lakehouse |
|---|---|---|---|
| Storage per TB | Highest | Lowest | Lake plus metadata |
| Compute billing | Per-second, vendor engine | Whatever engine you bring | Whatever engine you bring |
| Engineering to keep it correct | Lowest | Highest | Middle |
| Time to first trusted dashboard | Days | Months | Weeks |
| Who operates it | Analytics engineers on SQL | Platform engineers | Both, plus a specialist |
Storage is almost never the bill. Object storage can be five to ten times cheaper per terabyte than warehouse-managed storage, but on a 20 TB estate that saving is smaller than one extra engineer for a quarter. Lake economics start to win somewhere in the high tens to low hundreds of terabytes, and they win immediately if your data is not tabular. Look at current day rates for data and AI engineers before you model the saving, because the labour line moves the answer more than the storage line does.
Four questions that settle it
- Can you write down the schema of 80% of incoming data? If yes, a warehouse will do, and a lake adds cost without adding capability.
- Do you train models on raw documents, images or event streams? That points to a lake or lakehouse, because warehouses charge badly for blob storage and awkwardly for Python.
- Does your team write SQL or Python? A warehouse estate runs on SQL and a transformation framework. A lakehouse assumes someone is fluent in the compute engine’s internals.
- Do two or more engines need to read the same tables? Only that requirement forces an open table format.
Where each one fails
- Warehouses fail on non-tabular payloads and on vendor concentration. Compute and storage sit with one supplier, and moving a modelled estate elsewhere is a rebuild, not an export.
- Lakes fail on correctness and on erasure. A GDPR deletion request against a few hundred thousand Parquet files with no table format means rewriting every affected partition, and teams that have not planned for it find out the first time legal asks.
- Lakehouses fail on operational overhead. Streaming writes produce thousands of small files, query times degrade, and somebody has to own compaction, partitioning and file sizing. Without that person the bill drifts 30% to 50% above what the workload needs.
Where renting engineers is the wrong move
Two cases. If nobody internally owns the definition of a customer or an order, a rented team will build a technically correct platform that no department trusts, and the architecture choice will not rescue you. And if the work is a dated migration with a penalty clause attached, you want a supplier carrying fixed-price delivery risk rather than billed time. Our data engineering work is time and materials, and our notes on where migration budgets go set out what that shifts onto you.
For everyone else the sequence is dull and it holds: warehouse first, lake when the data stops being tabular, table format when a second engine needs the same rows. If you already know which of the three you need, we can place senior data engineers inside your team within a few weeks.