Did Iceberg win the table-format war?

Summary

• The two specifications have been adding the same core capabilities. Apache Iceberg's version 3 spec introduced binary deletion vectors, row lineage tracking and a variant type, and the Delta Lake protocol defines deletion vectors, row tracking and a variant type as table features.
• One copy of Parquet data can serve readers of both formats. Delta Lake's Universal Format (UniForm) writes Iceberg metadata asynchronously after Delta commits, and Apache XTable, an ASF incubating project, writes metadata for other formats so existing data files can be read through Delta Lake, Iceberg or Apache Hudi.
• Several open-source engines document support for both formats: DuckDB through its delta and iceberg extensions, Polars through scan_delta and scan_iceberg, and Apache Spark through each project's connector.
• The choice that matters is the shared catalog, the spec features every engine supports, and whether a second format needs reads only or writes too.
• Databricks supports both formats; Managed Iceberg, Iceberg v3 and Foreign Iceberg became generally available on Databricks in May 2026.

Did Iceberg win the table-format war?

There's no finish line in the projects' own record. Read the two specifications side by side and they describe the same core capabilities, from deletion vectors to row-level lineage to a variant type for semi-structured data, each added through the format's own versioning. The ecosystem also documents ways for one copy of Parquet data to serve readers of both formats. For a 2026 decision, focus on the catalog your engines share, the features they support, and whether you need one format or readable copies in both.

Where the two specifications line up

Every Delta cell traces to the transaction log protocol, and every Iceberg cell to the project's specs.

Capability	Delta Lake protocol	Apache Iceberg spec
Row-level deletes without rewriting files	Deletion vectors mark rows as logically deleted while they stay in the data file (deletionVectors)	Delete files since version 2; binary deletion vectors in version 3
Stable row identity across versions	Row tracking exposes Row IDs and Row Commit Versions (rowTracking)	Row lineage tracking in version 3
Semi-structured data	variant data type (variantType), with optional variant shredding	variant type in version 3
Concurrency model	Writers optimistically write files, then commit an atomic version to the log; multi-version concurrency control	An atomic swap of the table metadata file is the basis for serializable isolation
Catalog's role in commits	Catalog-managed tables make the catalog the source of truth for whether a commit succeeded	A REST catalog protocol gives engines one OpenAPI-defined API for any Iceberg catalog

The data layer overlaps too. Delta Lake stores data in Parquet files, and Iceberg's spec covers Parquet, Avro and ORC data files.

How one table serves both formats

• Universal Format (UniForm) in Delta Lake. After a Delta write completes, Delta Lake generates Iceberg metadata asynchronously on the same compute, so Iceberg clients can read the table. The upstream docs call it "read-only from an Iceberg and Hudi perspective," and they point to REORG, which rewrites the underlying data files, when a table has deletion vectors enabled.
• Apache XTable. It reads a table's existing metadata and writes metadata for one or more other formats under the table's base path (_delta_log for Delta, metadata for Iceberg), so the existing data files can be read through either format.
• Engines that read both. DuckDB and Polars document readers for both formats, and the Delta Lake and Iceberg projects each ship Apache Spark integrations, so readers don't have to share the writer's format.

Enabling Iceberg metadata on a new Delta table takes two table properties, as the Delta Lake docs show. Upstream, Spark also needs the delta-iceberg package and a Hive Metastore catalog.

CREATE TABLE events (id BIGINT, payload STRING) USING DELTA TBLPROPERTIES(
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg');

Questions that settle the format choice

• Which catalog will every engine use? Iceberg's docs note that "multiple types of compute engines using a shared Iceberg catalog allows them to share a common data layer."
• Do other engines need to read, or also write? Metadata translation covers reads. Writes still go through each table's native format, so pick the format your writers support.
• Which spec version can every engine handle? Iceberg says tables "may continue to be written with an older version of the spec to ensure compatibility." On the Delta side, the UniForm docs warn that reader and writer protocol upgrades "cannot be undone," so upgrade only when every reader is ready.

How Databricks approaches the format question

Unity Catalog manages Delta Lake and Iceberg tables side by side. Databricks' May 2026 announcement moved Managed Iceberg, Iceberg v3 and Foreign Iceberg to general availability, with deletion vectors, row tracking and the VARIANT type supported across managed, foreign and UniForm-enabled tables. The same post states the goal of advancing Iceberg "in a way that brings Iceberg and Delta Lake closer together." Its June 2025 post said Iceberg v3 features such as deletion vectors, the Variant data type and row IDs "share identical implementations in Delta Lake."
For Delta tables on Databricks, Iceberg reads (UniForm) need the same two table properties, column mapping, Unity Catalog registration and Databricks Runtime 14.3 LTS or above for writes. Iceberg client support is read-only.

FAQs

Do Delta Lake and Iceberg tables need different data files?

Not for Parquet. Delta Lake's data files are Parquet, and Iceberg supports Parquet alongside Avro and ORC. UniForm relies on that shared Parquet layer to serve both formats from one copy.

Can Iceberg engines write to a Delta table through UniForm?

No. The Delta Lake docs describe UniForm as read-only from the Iceberg and Hudi side, and Databricks documents Iceberg reads as read-only for Iceberg clients.

Is Iceberg v3 supported on Databricks?

Yes. The May 2026 announcement made Iceberg v3 generally available on Databricks, and the platform docs list spec version 3 next to versions 1 and 2.