Databricks adds Iceberg catalog handoff APIs in private preview

Databricks has introduced REGISTER and UNREGISTER APIs to transfer management of an Apache Iceberg table from one catalog to another without copying, moving or rewriting its underlying files. The company says the APIs are available for Unity Catalog in private preview. The release follows other work in Databricks’ governance stack, including its recent Genie One MCP rollout in Unity Gateway.

The handoff is meant to leave one catalog in control at a time. Databricks says REGISTER on its own can leave the original and destination catalogs independently accepting commits for the same table. That split-brain state can fork the table’s history, produce inconsistent query results and cause silent data loss, according to the company.

A three-step catalog handoff

Databricks describes a three-step process:

1. Catalog A receives an UNREGISTER request, removes the table from its catalog and leaves the data and metadata files in their existing storage locations.
2. The UNREGISTER response returns the table’s latest metadata location.
3. Catalog B uses REGISTER with that pointer to attach the table under a selected name.

The Apache Iceberg REST catalog specification defines REGISTER as a POST request requiring a table name and metadata location. It defines UNREGISTER as an empty POST to the table’s /unregister resource. A successful UNREGISTER response contains the last metadata location and the corresponding table metadata.

Two safeguards in the specification govern the transition. The returned metadata must include every commit completed before UNREGISTER, while any later commit attempt through the old catalog must fail. The old catalog therefore relinquishes control before the destination catalog registers the returned pointer. Databricks says this ordering addresses the split-brain risk that arises when REGISTER adds a second catalog entry while the first remains active.

Operational work still applies

The endpoints do not eliminate the operational work of a production migration. Databricks says operators still need to stop writers safely and repoint jobs. The announcement does not specify required privileges, expected downtime, multi-table coordination, rollback behavior or recovery steps if REGISTER fails after UNREGISTER.

Databricks also did not list the supported source and destination catalogs, clouds, Iceberg table versions or client versions for the private preview. It gave no general-availability date or public rollout schedule and directed customers interested in testing the Unity Catalog implementation to contact their account team.