Data Lakehouse Architecture Diagrams: Iceberg, Delta Lake & Unified Analytics (2026)

A data lakehouse is a data platform architecture that combines the low-cost, flexible storage of a data lake with the transactional guarantees, schema enforcement, and performance of a data warehouse. It does this by layering an open table format — Apache Iceberg, Delta Lake, or Apache Hudi — on top of files sitting in ordinary object storage, turning a directory of Parquet files into something that behaves like a governed, queryable table.

This guide covers every layer of a data lakehouse architecture: object storage, open table formats, the catalog layer, multi-engine compute, governance, and streaming ingestion. It includes a comparison of the major table formats and ready-to-use prompt templates for generating accurate data lakehouse architecture diagrams.

What is a data lakehouse, and how is it different from a data warehouse or data lake?

A data lake is cheap, durable object storage (S3, GCS, ADLS) holding raw files — CSV, JSON, Parquet — with no built-in structure, transactional guarantees, or schema enforcement. This makes it flexible and inexpensive but also fragile: concurrent writes can corrupt data, there is no way to atomically update or delete rows, and query engines have to infer schema at read time. Over years of uncoordinated writes, most data lakes decay into what practitioners call a "data swamp."

A data warehouse (Snowflake, BigQuery, Redshift in their classic form) solves the structure problem by owning both storage and compute in a tightly coupled, proprietary system. You get ACID transactions, strong schema enforcement, and fast SQL — but at the cost of vendor lock-in, storage priced at a premium relative to raw object storage, and difficulty letting non-SQL engines (Spark jobs, Python data science workloads) read the same data efficiently.

A data lakehouse aims to capture the best of both. Data still lives as Parquet files in cheap, vendor-neutral object storage, but an open table format layer on top adds ACID transactions, schema evolution, partition pruning, and time travel — the same guarantees a warehouse provides. Because storage and compute remain decoupled, multiple engines (Spark, Trino, Snowflake, DuckDB) can read and write the same underlying tables without copying data between systems, and you are never locked into a single vendor's storage format.

Key components of a data lakehouse architecture

Object storage layer

The foundation of every lakehouse is a durable, cheap object store — Amazon S3, Google Cloud Storage, or Azure Data Lake Storage (ADLS). Data is physically stored as columnar Parquet files (occasionally ORC), organized into directories that the table format layer above tracks and manages. This layer has no opinion about tables, schemas, or transactions — it is purely a durable, horizontally scalable file system that everything else builds on.

Open table format

The open table format — Apache Iceberg, Delta Lake, or Apache Hudi — is what turns a folder of Parquet files into a real table. It maintains a metadata layer that tracks which files currently belong to a table, enabling ACID transactions (so concurrent writers never corrupt data), schema evolution (adding, renaming, or dropping columns without rewriting the whole dataset), partition pruning (skipping irrelevant files at query time), and time travel (querying the table as it existed at a prior snapshot). This is the layer that most sharply distinguishes a lakehouse from a plain data lake.

Catalog / metastore

The catalog (also called a metastore) is the directory service that tracks which tables exist, where their metadata files live, and which snapshot represents the current state of each table. Unity Catalog, AWS Glue Data Catalog, Apache Polaris, and Project Nessie are common choices. The catalog is what allows multiple independent compute engines to discover and safely access the same tables — without it, each engine would need its own out-of-band way of knowing what data exists and where, which quickly breaks down as the number of engines and teams grows.

Compute engines

Because the lakehouse decouples storage from compute, multiple query engines can read and write the same tables through the catalog: Apache Spark for large-scale batch ETL, Trino or Presto for federated interactive SQL, Snowflake and Databricks for managed warehouse-style workloads, and DuckDB for lightweight local or embedded analytics. Teams typically pick the engine that best fits each workload rather than forcing everything through a single query layer, while continuing to share one physical copy of the data.

Governance and access control layer

With multiple engines touching the same tables, governance has to be enforced centrally rather than per-engine. A governance layer — typically built into the catalog itself (Unity Catalog) or bolted on via a policy engine — handles row- and column-level security, PII masking, and data lineage tracking, so that access rules apply consistently no matter which engine a user connects through.

Streaming ingestion into the lakehouse

Modern lakehouses increasingly ingest data continuously rather than in nightly batch loads. Change data capture (CDC) tools (Debezium, Fivetran) and streaming writers (Spark Structured Streaming, Flink) land new records into Iceberg or Delta tables within minutes of the source change, using the table format's ACID guarantees to make each micro-batch commit safely alongside concurrent batch jobs reading the same table.

Open table format comparison

Data lakehouse architecture patterns with prompt templates

Snowflake + Iceberg lakehouse for a BI/analytics team

Databricks Delta Lake medallion architecture for a data platform team

Streaming lakehouse with Kafka CDC ingestion into Iceberg

Common mistakes in data lakehouse architecture

• No catalog layer, or multiple uncoordinated catalogs — without a single source of truth for table metadata, different engines can silently diverge on what the current state of a table is, leading to inconsistent query results across teams
• The small-file problem from unbatched streaming writes — writing every micro-batch as its own tiny Parquet file quickly produces millions of small files that tank query performance; streaming writers need batching and regular compaction
• Ignoring partition and compaction maintenance — table formats do not clean themselves up automatically; skipping scheduled compaction, manifest rewriting, and snapshot expiration causes query latency to degrade steadily over months
• Treating the lakehouse as a dumping ground without a layering convention — landing raw and transformed data side by side with no bronze/silver/gold (or equivalent) structure makes it impossible for consumers to know which tables are safe to query
• Opening multi-engine access before row- and column-level governance is in place — once several engines can read a table directly, a single central policy point (usually the catalog) becomes the only place governance can be reliably enforced
• Mixing table formats within the same domain without a clear ownership boundary — Iceberg and Delta tables can coexist in one lakehouse, but doing so without documenting which team owns which format creates tooling fragmentation and duplicate pipelines
• Underestimating the cost of migrating between table formats — converting a large existing Delta Lake estate to Iceberg (or vice versa) involves rewriting metadata and often re-validating downstream jobs; this is a multi-quarter effort at scale, not a config change
• Skipping schema evolution testing — allowing upstream schema changes to flow into the lakehouse without validation can silently break downstream consumers that assumed a fixed column set

Frequently asked questions about data lakehouse architecture

What is the difference between a data lake, data warehouse, and data lakehouse?

A data lake is cheap object storage holding raw files with no transactional guarantees or enforced schema. A data warehouse is a tightly coupled storage-and-compute system that provides ACID transactions and strong schema enforcement, but at higher storage cost and with vendor lock-in. A data lakehouse layers an open table format (Iceberg, Delta Lake, or Hudi) on top of cheap object storage to get warehouse-like ACID transactions, schema enforcement, and time travel while keeping storage and compute decoupled and the data format vendor-neutral.

Should I choose Apache Iceberg or Delta Lake?

Both provide the same core capabilities — ACID transactions, schema evolution, time travel, and partition pruning — and the gap between them has narrowed as Delta Lake's UniForm feature adds Iceberg-compatible reads. Choose Delta Lake if your stack is already centered on Databricks and Spark, where the integration is deepest. Choose Apache Iceberg if you need broad multi-engine support across Snowflake, Trino, Spark, and others, or if avoiding lock-in to any single vendor's roadmap is a priority — Iceberg is governed by the Apache Software Foundation rather than a single company.

Can multiple compute engines (Spark, Snowflake, Trino) really share the same lakehouse tables?

Yes — that is the core promise of the lakehouse pattern. As long as every engine reads and writes through the same catalog and respects the same open table format, they see a consistent view of the data without copying it. In practice this requires the catalog to be a genuinely shared component (Glue, Unity Catalog, Polaris, or Nessie) rather than an engine-specific metastore, and it requires governance policies to be enforced at the catalog level so access rules apply uniformly no matter which engine a user connects through.

Related guides: modern data stack architecture, dbt architecture diagrams, data mesh architecture diagrams, and Kafka architecture diagrams.