What is the difference between Apache Iceberg and Delta Lake?

Both are open table formats that add ACID transactions, time travel, and schema evolution to Parquet files in object storage. Iceberg tracks state through a catalog pointer to immutable metadata files and manifest lists, and supports hidden partitioning plus partition evolution. Delta Lake tracks state through an ordered JSON transaction log with periodic checkpoints, and is deeply integrated with Databricks and Spark. Delta UniForm and Iceberg REST catalogs have narrowed the interoperability gap.

Which engines support Iceberg and Delta Lake?

Iceberg has the broadest multi-engine support: Spark, Trino, Flink, Snowflake, BigQuery, Athena, Dremio, DuckDB, and ClickHouse. Delta Lake is strongest on Spark and Databricks, with growing support through delta-rs, DuckDB, Trino, and Microsoft Fabric. If several independent engines must write the same tables, Iceberg is usually the safer default.

Can I use Iceberg and Delta Lake together?

Yes. Delta UniForm writes Iceberg metadata alongside Delta metadata so the same Parquet files can be read by Iceberg clients, and Iceberg REST catalogs let Databricks, Snowflake, and Trino share one catalog. Avoid concurrent writes from two formats to the same table; pick one writer and expose the other as a read path.

Is partition evolution possible in Delta Lake?

Delta Lake does not support changing a table's partition columns in place the way Iceberg does; the common alternative is liquid clustering, which lets you change clustering keys without rewriting the whole table. Iceberg's partition evolution changes the partition spec for new data while old data keeps its original layout.

Comparison · 2026

Apache Iceberg vs. Delta Lake: A 2026 Comparison

Apache Iceberg vs. Delta Lake compared: metadata design, schema and partition evolution, engine support, and how to pick a table format.

TL;DR

Choose Apache Iceberg when many independent engines — Spark, Trino, Flink, Snowflake, BigQuery — need to read and write the same tables, or when your partitioning strategy will change as the data grows. Choose Delta Lake when Databricks and Spark are the center of your platform and you want the tightest integration with Unity Catalog, liquid clustering, and streaming. The file layer is Parquet either way, so this is a metadata and ecosystem decision, not a storage one.

Metadata: manifests vs. a transaction log

Iceberg keeps a catalog pointer to the current metadata file, which references a manifest list, which references manifests, which reference data files. Every commit writes new immutable metadata and atomically swaps the pointer. Planning a query means pruning manifests by column statistics, so it stays fast on tables with millions of files.

Delta Lake keeps an ordered transaction log (_delta_log) of JSON commits with periodic Parquet checkpoints. It is simpler to reason about and debug, and on Databricks the log is served from a managed commit service that removes most of the object-store listing cost.

Schema and partition evolution

Both formats do safe schema evolution — add, drop, rename, and reorder columns — because both track columns by ID rather than by position in the file.

The real divergence is partitioning. Iceberg has hidden partitioning (the query engine derives partition values from a transform such as days(ts), so consumers never write partition predicates by hand) and partition evolution (change the spec going forward without rewriting history). Delta's answer is liquid clustering: no partition columns at all, with clustering keys you can change later and incremental re-clustering in the background. In practice liquid clustering solves the same "we picked the wrong partition key" problem, just differently.

Engine and ecosystem support

Iceberg has the widest independent engine support — Spark, Trino, Flink, Presto, Snowflake, BigQuery, Athena, Dremio, DuckDB, ClickHouse — and the Iceberg REST catalog has become the de-facto interchange standard. Delta Lake is strongest inside Spark and Databricks, with Microsoft Fabric, delta-rs, DuckDB, and Trino covering most of the rest. Delta UniForm writes Iceberg metadata next to Delta metadata over the same Parquet files, so a Databricks writer can serve Iceberg readers without a copy.

Streaming, upserts, and maintenance

For continuous ingestion, Delta plus Structured Streaming and Auto Loader is still the smoothest path, and deletion vectors make merge-heavy CDC workloads cheap. Iceberg pairs naturally with Flink for streaming upserts and has its own merge-on-read path with position and equality deletes. Either way, budget for maintenance: compaction, snapshot expiry, and orphan-file cleanup are not optional at scale — unmaintained tables get slow long before they get expensive.

Decision matrix by platform

Lean Iceberg

• Multi-engine estate (Trino, Flink, Snowflake, BigQuery)
• AWS-centric stacks using Athena, EMR, or Glue
• Partitioning strategy still in flux
• Vendor-neutrality is an explicit requirement

Lean Delta Lake

• Databricks or Spark-first platform teams
• Azure stacks with Microsoft Fabric and OneLake
• Heavy streaming and CDC merge workloads
• Unity Catalog governance and lineage in place

A pragmatic middle path for most enterprises: write Delta on Databricks, enable UniForm, and register tables in an Iceberg REST catalog so every other engine reads the same files. You get one writer, one copy, and no format war.