Apache XTable
A zero-copy metadata translator (Apache incubating, formerly OneTable) that converts between Iceberg, Delta Lake, and Hudi metadata without copying data files.
Summary
A zero-copy metadata translator (Apache incubating, formerly OneTable) that converts between Iceberg, Delta Lake, and Hudi metadata without copying data files.
XTable sits between table formats and query engines, enabling a "write once, read from any format" pattern. Ingest data in Hudi (optimized for CDC) and serve it to Trino and Snowflake via Iceberg metadata — all without data duplication.
- Zero-copy means no data file duplication, but metadata translation still has a cost. Large tables with millions of files can have non-trivial translation overhead.
- Still in Apache incubation. Documentation and build tooling are rough. Production use requires careful testing.
enablesApache Iceberg, Delta Lake, Apache Hudi — cross-format metadata translationsolvesVendor Lock-In — prevents table format lock-incompetes_withDelta UniForm — different approaches to interoperability
Definition
A metadata translation layer (Apache incubating, formerly OneTable) that performs zero-copy conversion between Apache Iceberg, Delta Lake, and Apache Hudi metadata. No data files are copied or modified — only metadata is translated.
Organizations ingest data in one table format (e.g., Hudi for low-latency CDC) but need to serve it to engines that prefer another format (e.g., Iceberg for Trino/Snowflake). XTable eliminates the need to maintain multiple copies of the same data in different formats.
Cross-format interoperability without data duplication, enabling multi-engine access to a single dataset, format migration pathways.
Recent developments
v0.3.0-incubating release — CatalogSync + continuous sync + restore/rollback. Per the apache/incubator-xtable releases page, v0.3.0-incubating ships CatalogSync for AWS Glue and Hive Metastore (so XTable now writes the cross-format metadata into the catalog tier, not just the file tier), continuous sync mode, restore and rollback semantics, the bucket-partition transform, schema field comments,
timestamp_ntzsupport, and upgraded parquet-avro to 1.15.1. Combined, these move XTable from "convert metadata when you ask" to "keep metadata in sync continuously across catalogs" — a real operational shape change for teams running multi-format catalogs.Incubator health check (Q2 2026): active community, two graduation blockers, hard translation limits. ASF board reports show bi-weekly dev syncs with contributors from Onehouse, Microsoft, and independents; graduation prospects are rated strong but gated on release cadence and completing the Delta Kernel API integration (PR #801 — would replace reverse-engineered Delta log parsing with protocol-tracking Kernel reads). Production-grade pairs are Hudi↔Iceberg and Delta↔Iceberg/Hudi for batch/copy-on-write only — Hudi MOR logs, Delta Deletion Vectors, and Generated Columns do not translate, and transaction timestamps aren't synced exactly. Know the limits before betting a mixed estate on retroactive translation. Per ASF board minutes — XTable and XTable features and limitations.
Apache incubation positioning still load-bearing. Per the project's official ASF page, Apache XTable reads existing table metadata and writes metadata for other formats, enabling reads across Delta, Hudi, and Iceberg from any cloud. The project remains under Apache incubation; the framing for organizations evaluating it: XTable is the Apache-incubated answer to the cross-format-metadata translation problem, parallel to but distinct from Delta UniForm's Delta-side approach.
XTable adds a REST Service. ASF board minutes from February 2026 note that XTable's recent development includes a new REST Service, alongside the 0.3.0 release's ability to sync tables to catalogs across multiple table formats — moving XTable toward a network-callable sync surface rather than a library/CLI-only tool. Per Board Meeting Minutes - XTable (Apache Whimsy).
XTable's conversion is omnidirectional; Delta UniForm's is unidirectional — the two dominant 2026 interop strategies split cleanly on this axis. XTable translates Iceberg, Delta, and Hudi metadata in any direction without copying the underlying Parquet files, so the same physical dataset can be read as any of the three formats regardless of which one wrote it; Delta UniForm instead asynchronously generates Iceberg (and Hudi) metadata from a Delta table — a one-way publish, not a translation layer. For teams choosing between the two: XTable fits a genuinely mixed-write estate, UniForm fits a Delta-primary estate that needs Iceberg-side readers. Per Iceberg REST Catalog, Actually Explained (Datastrato). Sources: apache/incubator-xtable releases (GitHub) · Apache XTable (Incubating) — official project page
Connections7
Outbound6
Inbound1
depends_on1Resources3
Official Apache XTable project site documenting zero-copy metadata translation between Iceberg, Delta, and Hudi.
Source repository with build instructions, supported format versions, and configuration guides.
Practical comparison of XTable vs. Delta UniForm for interoperability, covering when to choose each approach.