Skip to content
METRIC OAK

New: the 3-week Data Platform Assessment: fixed fee, priced roadmap. See what's included →

Comparison

Delta Lake vs Apache Iceberg: how they differ, and how to choose

Delta Lake and Apache Iceberg both add ACID transactions to Parquet files in cloud storage. How their metadata differs, which platforms favour each, how UniForm, OneLake and Snowflake now bridge them, and a practical way to choose.

Hemant Walchale

Hemant Walchale
· 4 min read

Delta Lake and Apache Iceberg solve the same problem: turning Parquet files in cloud storage into reliable tables with transactions, schema evolution and time travel. That is what makes a lakehouse possible. A few years ago choosing between them felt like a long-term bet. Today the formats are converging, and the more important choices are your platform and your catalog.

Delta Lake, a Linux Foundation project created by Databricks, keeps an ordered transaction log of JSON commits and Parquet checkpoints over Parquet data files and is native to Databricks and Microsoft Fabric. Apache Iceberg, an Apache Software Foundation project created at Netflix, uses a catalog pointing to metadata.json, manifest lists and manifests over the same kind of Parquet data files and is native to Snowflake, AWS, Trino, Dremio and others. The formats are converging: Delta UniForm writes Iceberg metadata, OneLake virtualizes Delta and Iceberg, and Snowflake reads Delta as Iceberg.

Side by side

Delta Lake Apache Iceberg
Origin and governance Created by Databricks, now a Linux Foundation project Created at Netflix, an Apache Software Foundation project
Metadata Ordered transaction log (_delta_log) with JSON commits and Parquet checkpoints Metadata files, manifest lists and manifests; a catalog points to the current metadata
Catalog Often Unity Catalog or a metastore; the log in storage defines the table Required: REST catalogs (such as Apache Polaris or Snowflake Open Catalog), AWS Glue, Unity Catalog and others
Native platforms Databricks, Microsoft Fabric (OneLake) Snowflake, AWS (Athena, EMR, S3 Tables), Trino, Dremio, many open engines
Row-level deletes Deletion vectors Position deletes in v2; deletion vectors in format v3
Partitioning Partition columns, plus liquid clustering on Databricks Hidden partitioning with transforms, and partition evolution

Both support ACID transactions, schema evolution and time travel. Performance differences depend far more on the engine and its optimisations than on the format.

Convergence: you rarely have to pick just one

  • Delta UniForm writes Iceberg metadata alongside the Delta log, so Iceberg readers can read Delta tables.
  • Microsoft Fabric OneLake virtualizes metadata in both directions: Delta tables gain Iceberg metadata, and shortcuts to Iceberg tables appear as Delta tables. It currently produces Iceberg v2 metadata and has limits on some partition transforms and v3 types.
  • Snowflake manages Iceberg tables natively and can read Delta tables in object storage as Iceberg tables through Delta Direct.
  • Databricks acquired Tabular, the company founded by Iceberg’s original creators, in 2024, and supports Iceberg tables and REST catalog access through Unity Catalog.
  • Iceberg v3 (generally available from Iceberg 1.10) adds deletion vectors, a variant type, row lineage and default values, closing several feature gaps. Engine support for v3 still varies, so check before upgrading tables.

How to choose

  1. Follow your primary platform. Databricks or Fabric: Delta Lake. Snowflake or an AWS-centred open stack: Iceberg. Fighting the platform’s native format costs performance and features.
  2. Choose the catalog deliberately. With Iceberg especially, the catalog decides which engines can write, how access is governed, and where lock-in really lives.
  3. Use interoperability for cross-engine reads, and test the specific features you rely on (deletion vectors, types, partitioning) before depending on them.
  4. Keep one writer per table. Many engines can read; letting several engines write to the same table is where consistency problems start.

The short version

Delta Lake and Iceberg are both open table formats over Parquet with transactions and time travel; Delta uses a transaction log, Iceberg a catalog-anchored metadata tree. Use the format native to your main platform, choose your catalog carefully, and rely on UniForm, OneLake virtualization or Snowflake’s Delta support for cross-engine access. Our data platform engineering team designs open-format lakehouses, and our migration work often includes format decisions.

Related: what is a data lakehouse, what is Unity Catalog, Databricks vs Snowflake for financial services and Databricks vs Microsoft Fabric.

Sources

Further reading from other practitioners

Not sure where your own platform stands? Take the free 3-minute data platform scorecard, or see how we work on Databricks. Unfamiliar terms are explained in the data engineering glossary.

Frequently asked questions

What is the difference between Delta Lake and Apache Iceberg?

Both are open table formats that store data as Parquet files and add a metadata layer for ACID transactions, schema evolution and time travel. Delta Lake records changes in an ordered transaction log (_delta_log). Iceberg uses a tree of metadata files, manifest lists and manifests, with a catalog holding the pointer to the current table state. Delta is native to Databricks and Microsoft Fabric; Iceberg is native to Snowflake, AWS services and many open engines.

Is Iceberg better than Delta Lake?

Neither is better in general. Iceberg has the broadest multi-engine and multi-vendor support. Delta Lake is the default on Databricks and Fabric, with deep optimisation there. The formats are converging: Delta UniForm writes Iceberg metadata, OneLake can expose Delta tables as Iceberg and the reverse, and Snowflake can read Delta tables as Iceberg tables.

Can I use both Delta Lake and Iceberg?

Yes, and many organisations do. Keep one primary format per platform and use the interoperability features (UniForm, OneLake table format virtualization, Snowflake Delta Direct) for cross-engine access. Check each feature's limitations, for example on deletion vectors, Iceberg v3 types and partition transforms.

Have 30 minutes? Get a senior architect’s view of your data platform.

No sales deck. You talk to the engineer who would lead the work.

Book an architecture review