Unity Catalog vs Hive metastore: the differences, and how to move

The Hive metastore is Databricks' legacy table catalog for 1 workspace; Unity Catalog is the catalog for your whole account, shared by every workspace in a region. Unity Catalog adds what the Hive metastore never had: permissions for account-wide groups, built-in auditing, lineage, and governance of files, models and functions as well as tables. Databricks calls the per-workspace Hive metastore a legacy feature and recommends moving its tables.

If your workspace is older than Unity Catalog, you probably have both. The Hive metastore shows up as a catalog called hive_metastore, next to your Unity Catalog catalogs, and the question is how to move what is in it without breaking jobs. How Unity Catalog names and governs things is covered in Unity CatalogUnity CatalogDatabricks' governance layer: one place that names every table, file volume, model and function as catalog.schema.object, decides who may use each, and records lineage and access. and our course module Unity Catalog explained; this article is the comparison and the move.

The differences

2 rows trip people up most. Views: in the Hive metastore a view's owner must own every table it reads; in Unity Catalog, SELECT on them is enough. Joins: a query can join hive_metastore.sales.orders with main.sales.history, but only in the workspace that holds the Hive data. The same query fails in any other workspace.

Which tool moves which table

Databricks offers 4 ways in, and the right one depends on what kind of Hive table you have:

For a whole workspace (identities, permissions, storage locations and tables together), Databricks recommends its open-source UCX tool, which assesses the workspace and runs these steps as workflows.

SYNC TABLE main.sales.orders
FROM hive_metastore.sales.orders
SET OWNER `data-engineers`;

The commands

Register an external table without copying it. SYNC can be run again on a schedule to pick up changes to the Hive table, which suits a gradual move:

SYNC SCHEMA main.sales FROM hive_metastore.sales SET OWNER `data-engineers`;

Copy a managed Delta table into a Unity Catalog managed table:

CREATE OR REPLACE TABLE main.sales.orders
DEEP CLONE hive_metastore.sales.orders;

Then mark the old table, so anyone still reading it sees a warning in their notebook with a quick fix:

COMMENT ON TABLE hive_metastore.sales.orders IS
  'This table is deprecated. Please use main.sales.orders instead of hive_metastore.sales.orders.';

What changes after the move

• History. A cloned table starts with no history. Time travel to versions from before the migration is not possible, so keep the Hive table while you might need them. Our article on Delta Lake time travel limits explains what decides how far back a table goes.
• Partition commands. ALTER TABLE ... ADD PARTITION and other Hive partition commands are not supported on Unity Catalog tables.
• Groups. Grants must name account groups, not workspace-local ones. Recreate the groups at account level before you grant.
• The default catalog. Workspaces enabled for Unity Catalog by hand kept hive_metastore as the default catalog, so short names such as sales.orders still resolve there. Switch the default only when the code no longer needs Hive tables.
• The old metastore stays open. Clusters keep connecting to the Hive metastore after you migrate, until you disable that access. Turn it off when the last job has moved, so nothing quietly writes to the old copy.

What to do

1. List what is in hive_metastore: external, managed outside the DBFS root, managed inside it.
2. Run UCX's assessment if the workspace is large; for a few schemas, SYNC and DEEP CLONE are enough.
3. Move schema by schema, comment the old tables, and change jobs to 3-part names.
4. When nothing reads hive_metastore, disable access to it.

If you are choosing a platform rather than moving within one, Databricks vs Azure Databricks and Microsoft Fabric vs Databricks compare the options; Unity Catalog works the same on every cloud.