Architecture

What is a data lakehouse?

The lakehouse is what happens when open table formats give cloud object storage real database semantics. One copy of your data, warehouse-grade SQL, no vendor lock-in.
Start the bootcamp Read the Iceberg guide

The old world: two systems, two copies

For a decade, teams ran a data lake (cheap, flexible, unreliable) AND a warehouse (fast, reliable, expensive). ETL copied data from lake to warehouse. Storage was doubled, semantics diverged, governance was a nightmare, and the warehouse vendor owned the data in a format you couldn't read without them.

The lakehouse fix: metadata over object storage

Put an open table format (Apache Iceberg, Delta Lake, Hudi) on top of S3/GCS/ADLS. Suddenly you get:

  • ACID transactions on plain Parquet files
  • Schema evolution without rewrites
  • Time travel to any past snapshot
  • Row-level MERGE / UPDATE / DELETE (real CDC, real GDPR delete)
  • Any engine can read it — Spark, Trino, DuckDB, Snowflake, BigQuery, Flink

One storage layer serves BI, ML, streaming, and ad-hoc SQL. No copies.

The medallion architecture (bronze/silver/gold)

  • Bronze. Raw ingestion. Exact copy of source, schema-on-read. Preserves everything.
  • Silver. Cleaned, deduplicated, conformed. One row per real-world entity per timestamp.
  • Gold. Business-aggregated, denormalized for consumption. Feeds dashboards and ML features.

The 2026 reference stack

  • Storage — S3 / GCS / ADLS / R2
  • Table format — Apache Iceberg (default), Delta if you're all-in on Databricks
  • Catalog — Polaris, Nessie, Unity, AWS Glue, or a REST catalog
  • Batch transform — dbt on Snowflake / BigQuery / Databricks / DuckDB
  • Streaming — Kafka + Flink writing directly to Iceberg
  • Query — pick per workload: Snowflake for BI, Trino/DuckDB for ad-hoc, Spark for heavy transform

Learn to build one

DataForge covers the full lakehouse stack — Iceberg, dbt, Spark, Kafka, and warehouse-specific tuning — with hands-on projects instead of slides. Start with the bootcamp or drop straight into dbt and Kafka.

FAQ

What is a data lakehouse?
A data lakehouse is an architecture that puts warehouse-style features (ACID transactions, schema enforcement, BI-grade SQL, governance) directly on top of cheap cloud object storage. Instead of copying data from a lake into a warehouse, one storage layer serves both worlds — powered by open table formats like Apache Iceberg or Delta Lake.
Data lakehouse vs data warehouse — what's the difference?
A warehouse (Snowflake, BigQuery, Redshift) stores data in a proprietary format the vendor owns and charges you to compute against. A lakehouse stores the same tables as open Parquet files you own, in your own S3 bucket, queryable by any engine. Same SQL, same performance, no vendor lock-in on the data.
Data lakehouse vs data lake — is it just marketing?
No. A raw data lake is a folder of files with no transactional guarantees — concurrent writes corrupt it, schema changes break readers. A lakehouse adds a metadata layer (Iceberg / Delta / Hudi) that gives you atomic commits, schema evolution and time travel. Same storage, real database semantics.
Is Snowflake a lakehouse? Is Databricks?
Databricks is the original lakehouse — that's the pitch. Snowflake is warehouse-first but now reads Iceberg tables natively, so it can play the lakehouse role for open data. BigQuery has BigLake. The lines have blurred in 2026 — the meaningful choice is now open table format vs proprietary format, not vendor vs vendor.
How do I build a lakehouse in 2026?
Object storage (S3/GCS/ADLS) + open table format (Iceberg) + a catalog (Polaris, Nessie, Unity, or REST) + a query engine (Spark, Trino, DuckDB, Snowflake, BigQuery). Land raw data as bronze, clean it into silver, aggregate into gold — the medallion architecture. Ingest with dbt for batch, Kafka + Flink for streaming.

Ready to start?

7 days free. Then less than a coffee per month.

Start the bootcamp