One record, readable by the tools you already have: XTable and UniForm

The finance team runs its reports in Power BI over Microsoft Fabric. A subsidiary bought last year reports in Snowflake. The group’s data engineers prefer Trino. Each tool reads one table format well, so each has its own copy of the sales ledger, refreshed on its own schedule, and the quarterly margin exists in three slightly different versions until somebody picks one.

A company does not arrive at a new operating system empty-handed. It arrives with those tools, those habits and those copies. Hurukan’s record is designed to be read by them without being copied for them. Two projects make that possible, and understanding what they do and do not do is a sovereignty question, not a plumbing one.

Why translation is possible at all

Delta Lake, Apache Iceberg and Apache Hudi store data the same way: as Parquet files that are never edited. They differ in the metadata written next to those files — the list of which files make up the table now, the schema, the partitions, the statistics. A table format is a plan laid over the bricks, and the bricks are shared.

So a table written in one format can be given a second plan. Nothing is copied; a second set of metadata is written pointing at the same files, and an engine that reads the second format finds a table where it expects one. The Data layer that holds Hurukan’s record is in build, and this is one of the properties it is being designed around.

Apache XTable: a translator that runs beside the table

Apache XTable is an incubating project at the Apache Software Foundation. It reads the metadata of a source format and writes the metadata of one or more target formats “without copying or moving the underlying data files”. The current release is 0.4.0-incubating from August 2026 (checked 21 October 2026). It runs as a tool or a scheduled job, with a full sync that rebuilds the target metadata and an incremental sync that carries over only what changed since the last run.

Its documentation is honest about limits: Hudi and Iceberg tables with merge-on-read layouts are not supported, nor are Delta tables that use deletion vectors. Microsoft’s own description of OneLake states that it uses XTable to show tables in more than one format, which is a useful sign of where the project sits in the market.

Delta UniForm: a second plan written at commit time

Delta UniForm does the same job from inside Delta Lake. When it is enabled on a table, Delta writes Iceberg metadata (and, in preview, Hudi metadata) after each commit, asynchronously, so an Iceberg reader sees the table natively. It requires column mapping, a reader version of at least 2 and a writer version of at least 7, and the IcebergCompatV2 table feature. Delta 4.3.0 of June 2026 added atomic incremental Iceberg conversion (checked 21 October 2026).

The limits are the mirror of XTable’s: the Iceberg or Hudi side is read-only; deletion vectors, the VOID type and the change data feed do not carry across. In a Microsoft estate the effect is visible in OneLake, which virtualises Delta tables as Iceberg with a documented lag of a few seconds to a couple of minutes, for tables under five thousand commits.

	Apache XTable	Delta UniForm
Where it runs	beside the table, as a job	inside the Delta writer, at commit
Source formats	Delta, Iceberg, Hudi (and more in 0.4.0)	Delta only
Target formats	any of the three	Iceberg; Hudi in preview
Writes from the second side	no	no
Catalogue and permissions	not translated	not translated

What is translated and what is not

Metadata is translated. The list of files, the schema, the partitions, the statistics. Three things are not, and each of them is a decision that stays with the company.

The write format. One format remains the one that is written to. That is where the table’s owner sits, where retention is set and where a deletion under data-protection law is executed. The other formats are views of it.

The catalogue. A reader in Snowflake or Fabric still needs to be told where the table is and whether this person may read it. Translated metadata does not carry permissions. Hurukan keeps permissions on the server and the catalogue on infrastructure the company chooses, which is the substance of the security and sovereignty layer.

Features the other format does not know. A Delta table with deletion vectors or an Iceberg table read through a format that lacks a feature will either refuse the translation or show a different result. The test plan for such a table reads it through every format in use and compares row counts, aggregates and the lag between a write and its visibility on the other side. In Hurukan that test suite is something an agent can generate from the schema and a person approves before the second format is offered to anyone.

Lock-in in both directions

The usual worry about an operating system for the whole company is that it locks the company in. The record answers it from the inside: open formats, files and catalogue on the company’s infrastructure, readable by other engines. XTable and UniForm answer it from the outside: the tools the company already pays for keep reading the same record, in the format they prefer, with no copy to reconcile. Integrations with Microsoft 365 Copilot and the other assistants are planned, not live; the file formats under them are already open.

Which format Hurukan writes first is a choice about catalogue and estate rather than features, and it is made in The audit trail is a table.

A test you can run today

List the tables that exist in more than one tool in your company. For each, write down which copy is the one people trust, and when the others were last refreshed. If the second column is blank, that table is a candidate for one record with two plans instead of two tables with one name.