Delta UniForm (External Iceberg Reads) versus native Iceberg?
Summary
- A Delta table with Iceberg reads (UniForm) enabled stays a Delta table: Delta Lake writes it, and Iceberg metadata is generated after each commit so Iceberg clients can read the same Parquet files.
- A native Iceberg table is Iceberg end to end: Iceberg writers commit snapshots directly, and open-source Iceberg features such as partition evolution, branches and tags apply.
- The deciding question is who writes. If writers use Delta and Iceberg engines only read, keep Delta and enable Iceberg reads; if Iceberg engines must write, use native Iceberg.
- Iceberg reads carry constraints: Iceberg clients are read-only, column mapping is required, deletion vectors aren't supported for Iceberg v2 reads, and Iceberg metadata trails the Delta commit because it's generated asynchronously.
- On Databricks, Unity Catalog supports both patterns: Iceberg reads on Delta tables, and managed Iceberg tables that external engines read and write through the Iceberg REST Catalog API.
Delta UniForm (External Iceberg Reads) versus native Iceberg?
Choose by the writer. A Delta table with Iceberg reads (UniForm) enabled keeps Delta Lake as its only writer and gives Iceberg engines a read-only view of the same files. A native Iceberg table accepts writes from any Iceberg engine and supports Iceberg's own feature set. If your pipelines already write Delta and other engines only need to query the results, Iceberg reads avoid a second copy and a second format to operate. If an Iceberg engine has to write, or you depend on Iceberg features such as branches, tags or partition evolution, use a native Iceberg table.
What are Iceberg reads (UniForm)?
Databricks documents the feature as Iceberg reads. Open-source Delta Lake calls it Universal Format (UniForm), which "allows you to read Delta tables with Iceberg and Hudi clients." Delta Lake and Iceberg both store Parquet data files plus a metadata layer, so the feature keeps a single copy of the files and generates Iceberg metadata asynchronously after each Delta commit. Writes need Delta Lake 3.1 or above, and the open-source requirements add column mapping, minReaderVersion 2 or higher, minWriterVersion 7 or higher, and a Hive Metastore as the Iceberg catalog.
CREATE TABLE T(c1 INT) USING DELTA TBLPROPERTIES(
'delta.enableIcebergCompatV2' = 'true',
'delta.universalFormat.enabledFormats' = 'iceberg');
REORG TABLE table_name APPLY (UPGRADE UNIFORM(ICEBERG_COMPAT_VERSION=2));
The first statement enables it at creation. On Delta 3.3 and above, the same two properties work in ALTER TABLE ... SET TBLPROPERTIES for an existing table, and the REORG form rewrites data files, which you need when the table has deletion vectors enabled. A native Iceberg table, by contrast, is created through an Iceberg catalog, for example CREATE TABLE local.db.table (id bigint, data string) USING iceberg, and its snapshots and manifests are the table.
How they compare
| Aspect | Delta table with Iceberg reads (UniForm) | Native Iceberg table |
|---|---|---|
| Source of truth | The Delta transaction log; Iceberg metadata is generated from it | Iceberg metadata (snapshots and manifests) |
| Who can write | Delta Lake clients only; Iceberg clients read | Any engine that writes Iceberg through the catalog |
| Freshness for Iceberg readers | Trails each Delta commit until generation finishes; frequent commits can be bundled | Each committed snapshot |
| Version history | Delta and Iceberg versions don't align | One history |
| Catalog in open source | Hive Metastore | Any configured Iceberg catalog |
| Feature limits | Column mapping required; no deletion vectors; no VOID type; change data feed and the open Delta Sharing protocol work for Delta clients only | Hidden partitioning, partition evolution, branches and tags, row-level deletes |
| Maintenance | Delta OPTIMIZE and VACUUM |
Iceberg procedures such as expire_snapshots and rewrite_data_files |
One open-source caveat matters more than the rest. The Delta docs say the read-only rule "cannot be enforced", because the Iceberg view is registered in the Hive Metastore, and they warn that a non-Delta writer could destroy the Delta table and cause data loss. Treat Iceberg access to these tables as read-only by policy.
How Databricks approaches Delta and Iceberg
Databricks documents both formats in Unity Catalog. For Delta tables, Iceberg reads work on managed and external tables registered in Unity Catalog, with writes on Databricks Runtime 14.3 LTS and above. You enable them with the same two properties plus delta.columnMapping.mode, at creation or on an existing table from Databricks Runtime 15.4 LTS, and Databricks recommends delta.columnMapping.mode = id for new tables. Iceberg clients then read these tables, but can't write them, through Unity Catalog's Iceberg REST Catalog endpoint. DESCRIBE EXTENDED shows a Delta Uniform Iceberg section with converted_delta_version, and MSCK REPAIR TABLE <table-name> SYNC METADATA regenerates Iceberg metadata on demand. Iceberg v3 supports deletion vectors, so the deletion-vector limit applies to Iceberg v2 reads.
For native Iceberg, Unity Catalog managed Iceberg tables need Databricks Runtime 16.4 LTS or above and serverless compute, which Databricks uses to maintain their metadata. External Iceberg engines can read and write them through the Iceberg REST Catalog API with credential vending, and Unity Catalog handles snapshot expiration and file compaction. The documented limits: branching and tagging aren't supported, partition evolution works only from external engines, and expression-based partition transforms aren't supported.
FAQs
Can an Iceberg engine write to a Delta table with Iceberg reads enabled?
No. Iceberg client access is read-only, and writes aren't supported. When an Iceberg engine needs to write, use a native Iceberg table, such as a Unity Catalog managed Iceberg table.
Does enabling Iceberg reads copy my data?
No. One set of Parquet files serves Delta and Iceberg clients, and only Iceberg metadata is added. On Databricks, data files in these tables use Zstandard compression instead of Snappy.
Why does an Iceberg reader see an older version of the table?
Iceberg metadata is generated asynchronously after each Delta commit, and frequent commits can be grouped into one Iceberg commit. Compare converted_delta_version with the latest Delta version to see how far behind it is.
Can I turn Iceberg reads off?
Yes. Unset delta.universalFormat.enabledFormats. Column mapping stays on, and Delta reader and writer protocol upgrades can't be undone.
The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.