Data lakehouse vs data warehouse (and data lake): how to choose

Warehouse, lake or lakehouse is less a product choice than a decision about where the one governed copy of each dataset lives. This guide compares the three side by side, explains the two-tier problem that created the lakehouse, and works through two company profiles: a 60-person SaaS that should stay with a warehouse and a marketplace that should not.

The short answer

A data warehouse stores structured, cleaned data in tables optimized for SQL reporting. A data lake stores raw files of any type cheaply in object storage. A data lakehouse adds warehouse features (transactions, schemas, fast SQL) on top of lake storage using open table formats, so one copy of the data can serve both BI dashboards and machine learning.

If your work is mostly dashboards and SQL on structured data, a warehouse is simpler. If you also need large volumes of raw, semi-structured data for data science, or want to avoid copying data between a lake and a warehouse, a lakehouse fits better.

Data warehouse vs data lake vs data lakehouse

The lines are blurring: major warehouses now read and write open table formats, and lakehouse engines have fast SQL. The real question is less "which product category" and more "where does the single governed copy of each dataset live?"

Major warehouses now read open table formats, so the lines are blurring.

Why the lakehouse appeared

Many companies ran a two-tier architecture: raw data landed in a lake, then a subset was copied into a warehouse for BI. That meant two copies, two sets of permissions, pipelines to keep them in sync, and dashboards that were often a day behind the lake. Armbrust and colleagues (2021) argued that open table formats with transactions, indexing and caching could let one storage layer serve both, which is the lakehouse idea.

Worked example: two companies, two answers

Company A: B2B SaaS, 60 employees (sample figures)

• About 120,000 product events a day plus CRM and billing tables; roughly 47 million event rows a year.
• Use cases: weekly KPI dashboards, revenue reporting, cohort retention, ad hoc SQL by three analysts.
• No machine learning beyond a churn score that fits in a spreadsheet-scale model.

Answer: a warehouse. The data is structured and modest; a lake would add infrastructure without benefit. Use ELT: load raw events and SaaS sources, model them in SQL.

Company B: marketplace, 900 employees (sample figures)

• About 40 million events a day, roughly 32 GB of raw JSON daily, around 12 TB a year before compression; plus images, search logs and clickstream used for ranking models.
• Use cases: BI for 200 dashboard users, and data scientists training recommendation and fraud models on full raw history.
• Today: data lands in S3, a nightly job copies 15% of it into a warehouse; dashboards lag by a day and the two copies disagree.

Answer: a lakehouse. Store everything once in Parquet with an open table format, give analysts SQL on the same tables data scientists use, and drop the nightly copy. Compressed columnar storage for a year of events is on the order of 1–2 TB, so storage cost is minor; the gains are one copy, one permission model and fresher dashboards.

How to decide

Choose a data warehouse if:

• Most data is structured (events, transactions, CRM).
• Main consumers are analysts and dashboards.
• You want the fewest moving parts and a managed service.

Choose a data lakehouse if:

• You have large semi-structured or unstructured data (logs, text, images).
• Data science and BI need the same data.
• You already run a lake and copy into a warehouse, and the sync is painful.
• Open formats matter to avoid lock-in.

Either way, the hard part is not the storage; it is governance: definitions, ownership, access control and data lineage. See data governance and single source of truth.

Common mistakes

• Building a lake with no catalog or owners. It turns into a swamp no one trusts.
• Choosing a lakehouse for a small, structured dataset because it is fashionable.
• Copying everything twice "just in case" and never reconciling the copies.
• Ignoring personal data. Raw zones collect identifiers you do not need; minimize at ingestion.
• Measuring cost by storage alone. Compute, egress and engineering time dominate.

Getting analytics data into either

Product and web analytics events are often the largest table in either architecture. TapCub exports raw events as gzipped JSONL via raw data export, with IP truncation and identifier hashing already applied at collection. Load the files into warehouse tables or convert them to Parquet in your lakehouse, then join with billing and CRM data. The data pipeline guide covers the monitoring you should add around those loads.

Sources

• Armbrust, M., Ghodsi, A., Xin, R. and Zaharia, M. (2021). Lakehouse: a new generation of open platforms that unify data warehousing and advanced analytics. CIDR 2021.
• Inmon, W. H. (2005). Building the Data Warehouse, 4th ed. Wiley.
• Apache Software Foundation. Apache Iceberg documentation.