Format interoperability
Delta UniForm and Apache XTable: one copy of the data, readable as Delta, Iceberg or Hudi.
On this page
Show code in
Every code block on the page follows this.
You will learn
- Why teams want one table readable as several formats
- How Delta UniForm generates Iceberg metadata
- How Apache XTable translates metadata between formats
- The limits of interoperability today
Read first
- Open table formats · 3 min read
- Catalogs: Unity, Polaris, Iceberg REST · 3 min read
Comfortable with these? Read on.
Why it matters
Organisations end up with several engines that prefer different formats: Databricks writes Delta, Snowflake and Athena favour Iceberg, a streaming team uses Hudi. Copying data into each format doubles storage and creates consistency problems. Since the data files are the same Parquet, the only thing missing is the metadata.
Delta UniForm
CREATE TABLE sales (...) USING delta TBLPROPERTIES ( 'delta.enableIcebergCompatV2' = 'true', 'delta.universalFormat.enabledFormats' = 'iceberg');
- 1Writes happen through Delta as usual.
- 2After each commit, Delta asynchronously generates Iceberg metadata (metadata file, manifests) describing the same Parquet files.
- 3The table is registered in a catalog that serves it to Iceberg clients (for example Unity Catalog's Iceberg REST endpoint), and Iceberg engines read it as an Iceberg table.
UniForm requires some features to be compatible with Iceberg (for example column mapping), and some Delta features are restricted while it is on, such as deletion vectors in earlier versions. Iceberg readers get read access; writes go through Delta.
Apache XTable
Apache XTable (incubating, originally OneTable) is a standalone tool that reads one format's metadata and writes equivalent metadata for the others: Delta to Iceberg, Iceberg to Delta, Hudi to either, and so on. It runs as a job after commits, incrementally syncing only the changes since the last run.
| Delta UniForm | Apache XTable | |
|---|---|---|
| Where it runs | Inside Delta, on commit | A separate sync job |
| Directions | Delta → Iceberg (and Hudi) | Any to any of Delta, Iceberg, Hudi |
| Writes | Delta is the writer | The source format is the writer |
| Freshness | Right after each commit | As often as the sync job runs |
Limits
- One writer format: interoperability is read-mostly. Writing through two formats to the same files is not supported.
- Feature mismatch: features one format has and another lacks (certain delete representations, clustering metadata, type features) may be unavailable or restricted.
- Freshness lag: translated metadata can trail the source by seconds to minutes.
- Catalog alignment: readers must find the translated table through a catalog; see the Catalogs lesson.
Common mistakes
Writing to the same table through two formats
Assuming every feature translates
Ignoring metadata lag
Key takeaways
- All formats share Parquet data; only the metadata differs.
- Delta UniForm writes Iceberg metadata after each Delta commit.
- Apache XTable translates metadata between Delta, Iceberg and Hudi.
- Keep one writing format; expect some feature limits and lag.
Check yourself
3 questions1. Why can one set of data files be read as both Delta and Iceberg?
Show the answer
Both store data as Parquet; only metadata differs. Interoperability tools only need to produce the other format's metadata.
2. With UniForm, which format performs writes?
Show the answer
Delta. Delta writes; Iceberg metadata is generated for readers.
3. What does Apache XTable do?
Show the answer
Translates table metadata between formats without copying data. It syncs metadata across Delta, Iceberg and Hudi.
Go deeper
Open table formatsLakehouse
Catalogs: Unity, Polaris, Iceberg RESTLakehouse
Iceberg format v3
Primary sources: Delta: UniForm · Apache XTable