The data lakehouse is the architectural answer to a problem that has plagued analytics for twenty years. The data warehouse is fast but expensive, closed, and locked to its vendor. The data lake is cheap and open but unreliable, prone to corruption, and impossible to query with the confidence a business demands. The lakehouse takes the openness and cost of object storage and layers on the transactional guarantees of a warehouse, using an open table format as the bridge between them.
Data Lakehouse Architecture is a practical engineering guide to building that bridge. It starts from the history — why the warehouse and the lake each failed at what the other did well, and why every previous attempt to reconcile them fell short — then walks through the full stack that makes the lakehouse work today.
The book covers object storage as the foundation, and what its consistency, durability, and cost properties impose on everything above it. It covers the three dominant open table formats — Apache Iceberg, Delta Lake, and Apache Hudi — in depth: their metadata models, their transaction protocols, their update semantics, and the specific workloads where each is the right choice. It covers storage layout and file formats, the partition and sort decisions that determine query performance, and the small-file problem that every lakehouse eventually faces. It covers catalog and metadata management, the role a catalog plays in portability and governance, and the emerging standards that are making catalogs interoperable. It covers query engines — Trino, Spark, Snowflake, BigQuery, DuckDB — and the consequences of separating compute from storage.
It covers ingestion, both batch and streaming, and the specific patterns for CDC and event-driven pipelines that preserve the table format's transactional guarantees. It covers the medallion architecture and the data modeling practices that make bronze, silver, and gold layers meaningful rather than ceremonial. And it covers governance, security, and cost — the disciplines that turn a technical architecture into a sustainable platform.
Along the way it addresses the failure modes that quietly wreck lakehouse deployments: a metadata table that grows without bound because old snapshots are never expired, a partition scheme that produces millions of tiny files no engine can read efficiently, a concurrent write from two engines that corrupts the table because the catalog was not transactional, a copy-on-write table that rewrites gigabytes for a single-row update, a merge-on-read table that accumulates delta files and degrades over months, a lakehouse that becomes a data swamp because governance was deferred until after the data arrived. Each is presented with the failure, the countermeasure, and the operational tradeoff.
