How should a platform decide between a warehouse, a lake and a lakehouse for a given workload?
Show the full answer Hide the answer
By workload, not by architecture fashion
A warehouse fits structured, well-modelled data queried by many analysts with SQL, where query performance and concurrency matter, governance is required, and the data volume is manageable at warehouse storage prices. Business intelligence, reporting and metrics are its home.
A lake fits large volumes of raw, semi-structured or unstructured data, accessed by processing engines rather than by SQL analysts, where storage cost dominates and schema is applied on read. Machine learning training data and raw event archives are its home.
A lakehouse fits where both are needed over the same data — analytical SQL and machine learning access, with transactional guarantees, at lake storage prices. It exists because maintaining both a lake and a warehouse means two copies, two pipelines and a reconciliation problem.
The decisive questions
1. Who queries it, and how? SQL analysts with concurrency requirements point to a warehouse; processing engines reading whole columns point to lake storage.
2. Does it need updates, deletes or concurrent writes? If yes, a plain lake is out, which usually means a table format.
3. What is the volume, and what is the storage cost at that volume? Warehouse storage at petabyte scale is frequently prohibitive.
4. Does the same data serve analytics and machine learning? If so, one copy avoids the divergence that causes training/serving skew — which is the strongest lakehouse argument.
The failure to avoid
Maintaining both a lake and a warehouse with overlapping content and separate pipelines. They diverge, consumers must choose, and reconciliation becomes permanent work. If both exist, the relationship must be explicit: one is derived from the other, with the derivation being the only path.
The pragmatic position
Most organisations end with both, and the discipline is in the boundary. Raw and machine-learning data in lake storage with a table format; curated, modelled, business-facing data in a warehouse fed from it. One direction of derivation, one source of truth per entity.