Databricks has added REGISTER and UNREGISTER APIs to the Apache Iceberg REST catalog specification, offering a way to transfer a table’s catalog management without copying its data. The important detail is that the old catalog must explicitly hand over control before the new one takes over: otherwise, two catalogs could accept writes to the same table and leave readers with conflicting results.
Databricks Watch analysis
What happened
In a post published on 5 October, Databricks explains how REGISTER attaches an existing table to a catalog using its metadata location. UNREGISTER removes the table’s entry from the catalog currently managing it, leaves the underlying files untouched and returns the latest metadata location for the next catalog to use. The hand-off is then completed by registering the table with its new catalog.
Databricks says the APIs are available in private preview on Unity Catalog. A production migration still requires operational work, including safely stopping writers and repointing jobs. This is a hand-off mechanism, not a magic button that makes a live migration risk-free.
Why it matters
Open table formats can separate data and metadata from the systems that manage them, but that does not automatically make moving between catalogs safe. A clean transfer matters to teams trying to change catalog providers without rewriting or exporting large stores of data, and without leaving two systems believing they alone coordinate updates.
The distinction between UNREGISTER and DROP is particularly useful. Databricks says DROP can delete underlying data and metadata; UNREGISTER relinquishes catalog management without touching those files. That gives operators a more specific tool for portability, while the stop-writers and repoint-jobs steps remain firmly on the migration checklist.
Our read
This is a practical infrastructure change, not a promise that catalog switching is now effortless. The useful contribution is a standardised way to relinquish control and pass the next catalog the metadata pointer it needs. Teams can assess the preview against their migration plans, but should treat writer coordination and job updates as part of the work, not optional finishing touches.
What to watch
- Whether the APIs move beyond private preview and become available across more catalog implementations.
- How implementations handle metadata pointers and hand-offs in real migration workflows.
- What operational guidance Databricks publishes for stopping writers and repointing jobs.
Discussion spark: Would a standard hand-off API make you more willing to move tables between catalogs, or are writer coordination and job changes still the real obstacles?
Sources and evidence
- Unlocking Data Portability: Preventing Catalog Lock-in with REGISTER and UNREGISTER APIs | Databricks Blog (5 October 2026, 16:00 UTC)
not affiliated with or endorsed by Databricks