What's the state of Delta and Iceberg interoperability?
Summary
- As of October 2026, Delta Lake and Apache Iceberg interoperate mainly through Delta Lake's Universal Format (UniForm), which writes Iceberg metadata from Delta commits so Iceberg clients can read one copy of the Parquet files. Iceberg clients can read those tables but not write them.
- Delta Lake 4.3 (June 2026) moved UniForm to atomic, incremental Iceberg conversion, and Delta Lake 4.4 can create UniForm metadata atomically with the table. Its
delta-icebergmodule supports Spark 4.1 but isn't compatible with Spark 4.2. - The formats are converging at the spec level. Iceberg v3 adds deletion vectors, row lineage, the variant type and column default values, features Delta Lake already ships as deletion vectors, row tracking and default column values.
- The catalog layer is the other bridge. The Iceberg REST Catalog API lets engines load tables through one protocol, and Unity Catalog OSS is compatible with it.
- On Databricks, Iceberg reads (UniForm) work on Unity Catalog tables from Databricks Runtime 14.3 LTS, managed Iceberg tables are readable and writable from external engines, and Iceberg v3 features need Databricks Runtime 18 LTS or above.
What's the state of Delta and Iceberg interoperability?
Reading across formats works today; writing is still one-way. Delta Lake's Universal Format (UniForm) generates Iceberg metadata for a Delta table, so Iceberg clients query the same Parquet files without a copy, but those clients can't write to the table. Two trends are narrowing the gap: the Iceberg v3 spec adds features Delta Lake already has, and catalogs such as Unity Catalog OSS speak the Iceberg REST Catalog API. In open source, check version alignment too.
What works today, layer by layer
| Interop path | Where it stands (October 2026) | What to check |
|---|---|---|
| Iceberg clients reading Delta tables (Delta UniForm) | Iceberg metadata generated from Delta commits; one copy of the data files | Read-only for Iceberg clients; the UniForm docs list deletion vectors as unsupported, but the 4.3.0 release notes mention UniForm with deletion-vector tables |
| Spark versions for OSS UniForm | Delta Lake 4.3 and 4.4 ship delta-iceberg for Spark 4.1 |
Delta Lake 4.4's module isn't compatible with Spark 4.2 |
| Moving Delta tables into Iceberg | Iceberg's iceberg-delta-lake module offers a one-time Snapshot Table action |
Built against Delta Standalone 0.6.0; supports tables at reader version 1 and writer version 2 |
| Shared table features | Iceberg v3 adds deletion vectors, row lineage, variant and default values | Iceberg's status page shows v3 type support differing across its libraries |
| Catalog protocol | Iceberg REST Catalog API; Unity Catalog OSS is compatible with it | The OSS UniForm docs still list Hive Metastore as the required catalog |
How Delta Lake UniForm works in open source
UniForm "allows you to read Delta tables with Iceberg and Hudi clients" by writing Iceberg metadata alongside Delta's. Requirements per docs.delta.io: column mapping enabled, minReaderVersion 2 or higher and minWriterVersion 7 or higher, and writes from Delta Lake 3.1 or above. You enable it with two table properties:
CREATE TABLE orders (order_id BIGINT, amount DECIMAL(10, 2)) USING DELTA
TBLPROPERTIES (
'delta.enableIcebergCompatV2' = 'true',
'delta.universalFormat.enabledFormats' = 'iceberg'
);
This layer moves fast. Delta Lake 4.0 shipped without UniForm Iceberg support on Spark 4.0, and 4.1 (February 2026) restored it. Delta Lake 4.3 (June 2026) says UniForm "now writes Iceberg metadata atomically with the Delta commit" and converts only the changed log range, and 4.4 (August 2026) lets UniForm metadata be "initialized atomically with Delta table creation."
Three limits still matter. Iceberg clients "can only read from UniForm," and the docs warn that an external Iceberg writer "may destroy your Delta table and cause data loss." Delta and Iceberg version numbers don't align by commit timestamp or version ID, so UniForm records converted_delta_version and converted_delta_timestamp in the Iceberg metadata to map one to the other. Change data feed and the open Delta Sharing protocol work for Delta clients but have no Iceberg equivalent.
Where the formats are converging
The Iceberg v3 spec adds capabilities including nanosecond timestamps, variant, geometry and geography types, column default values, multi-argument transforms, row lineage, binary deletion vectors and table encryption keys. Several of these have Delta Lake counterparts: deletion vectors (Delta Lake 2.3.0 and above), row tracking (3.2.0 and above) and default column values (3.1.0 and above). Delta Lake 4.3's release notes already mention re-aligning Iceberg row lineage with Delta's baseRowId.
How Databricks approaches Delta and Iceberg interoperability
Databricks supports both formats in Unity Catalog. Iceberg reads (UniForm), available in Databricks Runtime 14.3 LTS and above, configure Delta tables registered in Unity Catalog to generate Iceberg metadata automatically, so Iceberg clients read Delta data without rewriting files. Unity Catalog implements the Iceberg REST catalog API at /api/2.1/unity-catalog/iceberg-rest, with credential vending for supported clients. Through it, managed Iceberg tables are readable and writable by external engines, while foreign Iceberg tables and Delta tables with Iceberg reads are read-only.
Iceberg v3 closes the deletion-vector gap on Databricks. With Databricks Runtime 18 LTS and above, managed Iceberg tables and managed Delta tables with Iceberg reads can use deletion vectors, VARIANT, row lineage, GEOMETRY and GEOGRAPHY, and write defaults:
CREATE OR REPLACE TABLE main.sales.orders (order_id BIGINT)
TBLPROPERTIES (
'delta.universalFormat.enabledFormats' = 'iceberg',
'delta.enableIcebergCompatV3' = 'true'
);
Databricks supports Iceberg tables that use Parquet and versions 1, 2 and 3 of the Iceberg spec, and Unity Catalog handles snapshot expiration and compaction for managed Iceberg tables.
FAQs
Can Iceberg engines write to a Delta table that uses UniForm?
No. Both the Delta Lake and Databricks docs describe Iceberg client support as read-only. For tables that Iceberg engines must write, use Iceberg tables, such as managed Iceberg tables in Unity Catalog.
Do I have to choose between Delta Lake and Iceberg?
Not for reads. Delta Lake and Iceberg both consist of Parquet data files plus a metadata layer, so one copy of the files can serve both kinds of client, and Unity Catalog governs both formats. Choose the table format by which engines need to write.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.