What is a Lakehouse? The Data Architecture, Defined

A lakehouse is a data architecture that combines the low-cost storage and unstructured-data support of a data lake with the ACID transactions and SQL ergonomics of a data warehouse, typically built on open table formats (Delta Lake, Iceberg, Hudi).

A lakehouse is a data architecture that combines the low-cost storage and unstructured-data support of a data lake with the ACID transactions, schema enforcement, and SQL ergonomics of a data warehouse. The architecture is typically built on open table formats (Delta Lake, Apache Iceberg, Apache Hudi) layered on object storage (S3, ADLS, GCS, OneLake).

What a lakehouse actually is

The architecture has three layers:

• Object storage: low-cost, highly durable file storage (S3, ADLS Gen2, GCS, OneLake) that holds the raw Parquet files.
• Open table format: a transactional layer (Delta Lake, Iceberg, or Hudi) that adds ACID transactions, schema evolution, time travel, partition management, and indexing on top of the raw files.
• Compute engine(s): Spark (Databricks), SQL engines (Databricks SQL, Snowflake external tables, Fabric Warehouse, Trino, Athena, BigQuery), and ML frameworks all read and write the same table format.

The shared property is decoupling: storage is owned by open formats on cheap object storage, and compute engines compete to read and write the same data without lock-in.

What people confuse it with

• "A lakehouse is the same as a data lake." Wrong. A data lake is just storage. A lakehouse adds the transactional table format layer on top.
• "A lakehouse is just a warehouse with cheaper storage." Closer but incomplete. The architectural shift is the open table format that decouples storage from compute, not just the storage cost.
• "Delta, Iceberg, and Hudi are equivalent." Functionally similar, ecosystem-distinct. Delta is Databricks and Fabric. Iceberg is Snowflake-friendly and Athena / Trino. Hudi is Uber, AWS Glue, streaming-heavy use cases.

When a lakehouse matters

A lakehouse matters when:

• The workload mixes structured (analytical) and unstructured (ML feature engineering, text, image) data.
• The organization wants to avoid storage lock-in to a single warehouse vendor.
• The compute engine choice needs to vary per workload (Spark for ML, SQL warehouse for BI, Trino for ad-hoc).

When a lakehouse does not help

A lakehouse does not help when:

• The workload is pure SQL analytics with high concurrent dashboard users, where a warehouse's tuned concurrency scaling wins.
• The organization is fully invested in a single warehouse stack (Snowflake-only, Redshift-only) and the open-table interop is not yet operationally needed.
• The team has no Spark or open-source culture and the lakehouse complexity outweighs the warehouse simplicity.

How Thinklytics works on lakehouse architectures

We scope lakehouse engagements with attention to table format choice, workload allocation, and the broader analytical architecture. See Microsoft Fabric data engineering and Snowflake vs Databricks AI workloads.

Frequently asked questions

What is a lakehouse in one sentence?

A lakehouse is a data architecture that combines the low-cost storage and unstructured-data support of a data lake with the ACID transactions, SQL ergonomics, and BI tool support of a data warehouse, typically built on open table formats (Delta Lake, Apache Iceberg, Apache Hudi).

Who coined the term lakehouse?

Databricks popularized the term starting in 2020, with the 'Lakehouse: A New Generation of Open Platforms' paper. The concept has older roots (Iceberg from Netflix, Hudi from Uber, both 2017) but the unified lakehouse pitch was Databricks-led.

How is a lakehouse different from a data lake?

A data lake is just storage (typically Parquet or CSV files on object storage). A lakehouse adds a table format layer on top (Delta, Iceberg, Hudi) that provides ACID transactions, schema enforcement, time travel, and BI tool compatibility, while keeping the open file storage.

How is a lakehouse different from a data warehouse?

A traditional data warehouse uses proprietary storage tightly coupled to its compute engine (e.g., Snowflake's micro-partitioned format, Redshift's column store). A lakehouse decouples storage (open files) from compute (Spark, Trino, Databricks SQL, Snowflake external tables, Fabric). The decoupling is the value.

Delta Lake vs Apache Iceberg vs Apache Hudi: which one?

Delta is the default for Databricks and Microsoft Fabric. Iceberg is the default for Snowflake's open-table support, AWS Athena, and Trino-heavy stacks. Hudi is most common at Uber, AWS Glue, and some streaming use cases. The 2025-2026 industry direction is toward Iceberg interop across all major platforms, with Delta and Hudi remaining strong in their native ecosystems.

Can I run SQL on a lakehouse?

Yes. Databricks SQL, Snowflake (against external Iceberg tables), Microsoft Fabric (Lakehouse SQL endpoint), Trino, Presto, AWS Athena, and Google BigQuery (against external tables) all run SQL against lakehouse tables. The lakehouse architecture explicitly supports both SQL and Spark / PySpark workloads on the same underlying files.

Does a lakehouse replace a warehouse?

For many new builds, yes. For organizations with mature Snowflake or Redshift footprints, the lakehouse usually emerges as a peer (often hosting unstructured data and ML feature engineering) rather than a replacement. The cross-vendor convergence in 2026 (Snowflake supports Iceberg, Databricks supports SQL warehousing) makes the distinction less sharp.

How does Thinklytics work on lakehouse architectures?

We scope lakehouse engagements with attention to table format choice (Delta vs Iceberg), workload allocation (Spark vs SQL), and the broader analytical architecture. See Microsoft Fabric data engineering and Snowflake vs Databricks AI workloads.