TL;DR: A Databricks metastore is the top-level container that registers metadata and access permissions for every catalog, schema, and table in a region. The account-level Unity Catalog metastore has replaced the legacy per-workspace Hive metastore, and Databricks allows exactly one per region. Most teams should create it through the account console, attach every regional workspace to it, and move Hive tables over with the SYNC command or UCX.
Working through an adjacent platform decision? See also Data Engineering Trends 2026 · AWS to Azure Migration .
Watch on YouTube
Databricks Unity Catalog Explained!
Kanerika’s team breaks down what Unity Catalog actually does for governance, and why the metastore behind it changes how enterprises secure their lakehouse.
Why the Metastore Decides How Governed Your Lakehouse Really Is Every access decision Databricks makes starts in the same place. Before a query touches a single Delta file, the platform asks the metastore what the table is, where it lives, and who may read it.
Yet most teams inherit their metastore layout rather than design it. Workspaces multiply, the legacy hive_metastore lingers next to Unity Catalog, and nobody remembers why production tables sit in three different places. The result is a governance model that auditors question and platform engineers quietly work around.
Getting the metastore layer right fixes that at the root. In this article, we’ll cover what a Databricks metastore is, how the Hive and Unity Catalog metastores differ, the one-metastore-per-region architecture, setup steps, the migration path from Hive, federation, best practices, and common errors.
Key Takeaways A Databricks metastore stores metadata and permissions for data and AI assets, and Unity Catalog makes it an account-level object rather than a workspace-level one. Databricks enforces one Unity Catalog metastore per region, and every workspace in that region attaches to the same metastore. The three-level namespace runs metastore to catalog to schema to table, so every object resolves as catalog.schema.object. The legacy Hive metastore still appears as a catalog named hive_metastore, but its tables miss lineage, auditing, and fine-grained access control. The SYNC command upgrades external Hive tables to Unity Catalog without copying data, while managed and DBFS-root tables need CTAS or deep clone. Hive metastore federation mirrors an external or legacy metastore as a foreign catalog, giving you governance now and migration later. What Is a Databricks Metastore? A Databricks metastore is the top-level container for data governance in the platform. It registers metadata about securable objects such as catalogs, schemas, tables, views, volumes, functions, and machine learning models , along with the permissions that control access to them.
The metastore does not hold your data. Delta and Parquet files stay in your cloud object storage, while the metastore records where each table’s files live, what its columns are, and which principals can query it. The Unity Catalog documentation describes it as the unit that exposes the full object hierarchy to every attached workspace.
Listen on Spotify
Types of Data Migration Every Enterprise Must Know in 2026
Two implementations matter in practice. The legacy Hive metastore is a per-workspace metadata store that Databricks inherited from Apache Spark, and the Unity Catalog metastore is the account-level replacement that anchors the platform’s Unity Catalog governance layer . Searches for “databricks meta store” as two words point to the same concept, and the one-word spelling is the correct form.
Understanding this container is step one in any Databricks lakehouse architecture decision. Everything else in governance, from lineage to row filters, hangs off the metastore you attach.
The Three-Level Namespace From Metastore to Table Unity Catalog organizes every asset in a strict hierarchy. The metastore sits at the top, catalogs sit inside it, schemas sit inside catalogs, and data objects sit inside schemas.
Every query addresses an object through this three-level namespace, written as catalog.schema.object. A sales table in the production catalog resolves as prod.sales.orders, which removes the ambiguity that two-level Hive naming forced on teams that ran many environments.
Catalogs usually map to environments, business units, or data domains. Many teams pair the namespace with a medallion architecture , keeping bronze, silver, and gold schemas inside each domain catalog so pipeline stages stay visible in the object name itself.
A few objects live directly under the metastore rather than inside any catalog. Storage credentials, external locations, connections, and Delta Sharing shares are metastore-level securables, which is why the metastore admin controls them no matter which workspace created them. Tables and volumes come in managed and external forms, and the metastore governs both while only managing the storage lifecycle of the managed ones.
Hive Metastore vs Unity Catalog Metastore The two metastore generations answer the same question, what does this table mean, with very different governance reach. The Hive metastore is workspace-scoped, so every workspace keeps its own private copy of table definitions. The Unity Catalog metastore is account-scoped, so one definition and one permission model serve every workspace in the region.
That scope difference drives everything else. Hive-registered tables have no built-in lineage, no central audit log, and access control that stops at coarse table ACLs. Unity Catalog adds automatic data lineage , centralized audit logging, row filters, column masks, and governance that extends past tables to models, volumes, and dashboards. It also anchors Databricks security features that the legacy store simply cannot see.
Table 1: Hive metastore vs Unity Catalog metastore
Dimension Hive metastore (legacy) Unity Catalog metastore Scope One per workspace One per account per region, shared by all attached workspaces Namespace Two levels (schema.table) Three levels (catalog.schema.object) Access control Legacy table ACLs, per workspace ANSI GRANT model plus row filters and column masks, account-wide Lineage and audit None built in Automatic lineage and centralized audit logs Asset coverage Tables and views only Tables, views, volumes, functions, models, and shares Sharing Manual exports or mounts Native Delta Sharing at the metastore level Status Legacy, kept for compatibility Default for all workspaces created after November 8, 2023
The legacy store does not disappear when Unity Catalog arrives. It surfaces inside the new namespace as a catalog named hive_metastore, so old two-level references keep working while you migrate. Databricks documents this coexistence in its legacy Hive metastore guide .
One caution for teams comparing governance options more broadly. This comparison covers the metastore layer inside Databricks, while the choice between Unity Catalog, Purview, and Collibra as an enterprise catalog is a separate decision we examine in our Unity Catalog vs Purview vs Collibra comparison and our roundup of data catalog tools .
One Metastore Per Region and How Workspaces Attach Databricks enforces a hard architectural rule. You can create exactly one Unity Catalog metastore per region in an account, and a workspace can only attach to a metastore in its own region.
The intent is a single source of truth. Every workspace in us-east-1 sees the same catalogs, the same grants, and the same audit trail, because they all resolve names against the same metastore. A workspace attaches to exactly one metastore at a time, and account admins manage the assignment from the account console, as described in the workspace enablement documentation .
Sharing one metastore does not mean every workspace sees every catalog. Workspace-catalog binding lets you restrict a catalog to specific workspaces, which is how most teams isolate production data from development compute inside a single regional metastore. It is a cleaner separation than the old habit of using separate workspaces as a permission boundary.
Cross-region access runs through Delta Sharing rather than cross-attachment. A share defined in one metastore can serve recipients on another metastore, another region, or another platform entirely, a pattern we cover in depth in our Databricks Delta Sharing guide .
Clear role separation keeps this shared container manageable. Four roles matter at the metastore layer.
Table 2: Admin roles around a Databricks metastore
Role Assigned where What it controls at the metastore layer Account admin Account console Creates metastores, assigns workspaces, names the metastore admin Metastore admin Metastore Owns catalogs, storage credentials, external locations, and shares; grants top-level privileges Workspace admin Workspace Manages compute, users, and workspace settings, but not metastore objects Catalog owner Catalog Grants schema and table privileges inside one catalog, delegates day-to-day access
Databricks recommends assigning the metastore admin role to a group rather than an individual. The person who creates the metastore owns it by default, and leaving that ownership with one account is a single point of failure that audits flag quickly.
How to Create and Attach a Databricks Metastore Creating a metastore is an account-level task, so you need an account admin identity on a Premium plan or above. The whole flow takes minutes once the cloud prerequisites exist. Follow these steps, which mirror the official create-metastore documentation .
Step 1: Decide on root storage. Metastore-level root storage is optional, and many teams skip it deliberately so that every catalog gets its own isolated storage location instead of sharing a default bucket.Step 2: Prepare the cloud resources. If you do want root storage, create the S3 bucket or ADLS container plus the IAM role or managed identity that Databricks will use to reach it.Step 3: Create the metastore in the account console. Open the Catalog section, choose Create metastore, name it, pick the region, and paste the storage path and credential if you configured them.Step 4: Attach workspaces. Select the workspaces in that region and assign them to the new metastore. Attachment enables Unity Catalog on each of them immediately.Step 5: Reassign the admin role. Transfer metastore admin from your personal identity to a platform governance group before anyone creates production catalogs.Teams that manage infrastructure as code can do the same thing with the Terraform provider, using the databricks_metastore resource and its assignment companion.
resource "databricks_metastore" "this" {
name = "primary-us-east-1"
region = "us-east-1"
storage_root = "s3://uc-root-us-east-1/metastore"
force_destroy = false
}
resource "databricks_metastore_assignment" "prod" {
metastore_id = databricks_metastore.this.id
workspace_id = var.prod_workspace_id
}Codifying the metastore pays off the first time you stand up a new region. A short Databricks proof of concept is the right place to rehearse this layout before production workloads depend on it, and the same definitions carry into any wider Databricks deployment .
Kanerika Service
Data Governance Services
Kanerika designs metastore layouts, catalog structures, and permission models that pass audits, then migrates your Hive estate onto them without breaking pipelines.
Explore Data Governance Services Migrating From Hive Metastore to Unity Catalog Most established Databricks estates still carry tables in the legacy store, and moving them is the real work of metastore modernization. The official upgrade guide frames the effort in four phases, and holding to that order avoids most rework.
Step 1: Assess. Inventory every Hive table with its type, format, and storage location. The open source UCX toolkit from Databricks Labs automates the assessment and flags objects that need special handling.Step 2: Create the Unity Catalog assets. Stand up the metastore, catalogs, schemas, storage credentials, and external locations that the upgraded tables will land in.Step 3: Upgrade the tables. Use SYNC for external tables, and CTAS or deep clone where data must move. Match the method to the table, not the other way around.Step 4: Grant and cut over. Apply Unity Catalog grants, repoint jobs and dashboards at three-level names, and retire the old references.The SYNC command is the workhorse because it copies no data. It reads the Hive table definition and registers an external Unity Catalog table over the same cloud storage path, as specified in the SYNC command reference .
-- Upgrade one external table
SYNC TABLE prod.sales.orders FROM hive_metastore.sales.orders;
-- Upgrade a whole schema, preview first
SYNC SCHEMA prod.sales FROM hive_metastore.sales DRY RUN;Managed Hive tables that live on the DBFS root cannot be synced in place, because that storage belongs to the workspace rather than to you. Those tables move with deep clone for Delta and Parquet sources, or CREATE TABLE AS SELECT for other formats, per the patterns in the Databricks migration blog .
Table 3: Choosing an upgrade method per table
Method Best for Data movement SYNC External tables on direct cloud paths None, metadata only Deep clone Managed Delta and Parquet tables, incremental re-runs Full copy with resumable increments CTAS Non-Delta formats and tables needing a rewrite Full copy HMS federation Estates that must keep the old metastore live during a long transition None, mirrored as a foreign catalog
Plan the cutover around your pipelines as much as your tables. Ingestion jobs built on Databricks Autoloader and transformation projects using dbt on Databricks both carry catalog references that must move to three-level names in the same release. Teams arriving from older stacks can fold this into a broader legacy-to-Databricks migration or a Hadoop-to-Databricks migration rather than running it as a separate project. Metastore design sits inside a broader modernization arc; the 2026 data engineering trends that surround it—streaming-first pipelines, open table formats, and data contracts—all depend on a sound catalog layer.
UCX: Databricks’ Purpose-Built Migration Toolkit Beyond the manual SYNC and CLONE commands, Databricks maintains an open-source toolkit called UCX specifically for Hive-metastore-to-Unity-Catalog migrations at scale. UCX assesses your existing Hive metastore for migration blockers (incompatible table formats, unsupported grants, workspace-local configurations), generates a migration workflow that handles table upgrades in bulk rather than one at a time, and produces a compatibility report before you touch production data.
For a handful of tables, manual SYNC TABLE commands are fine. For an enterprise catalog with hundreds or thousands of tables across multiple schemas, UCX’s batch assessment and bulk-upgrade workflow is the difference between a migration that takes days versus one that takes months of manual per-table scripting. It is the tool Databricks’ own field engineering teams reach for on large migrations, and it should be the first stop before hand-rolling a custom migration script.
Federating an External Hive Metastore Not every Hive metastore lives inside Databricks. Plenty of estates still run a self-hosted metastore database or AWS Glue as the shared catalog for Spark clusters, and rewriting every consumer at once is rarely realistic for teams comparing open source Spark with Databricks or moving off EMR.
Hive metastore federation solves the transition problem. Unity Catalog connects to the external or legacy metastore and mirrors it as a foreign catalog, so its tables become queryable and governable without moving a single file, as described in the federation concepts documentation .
The foreign catalog behaves like any other catalog for readers. You can grant on it, audit it, and trace lineage through it, while writes continue to flow through the original metastore that legacy jobs still use.
Treat federation as a bridge rather than a destination. It buys governance coverage on day one, keeps external engines working, and lets you upgrade tables into native Unity Catalog objects at your own pace.
Cross-Cloud and Cross-Region Metastore Patterns The one-metastore-per-region constraint feels limiting until you understand the architectural reasons behind it. A Unity Catalog metastore is a regional control plane object — it stores metadata and enforces access policies inside a single cloud region’s trust boundary. Moving metadata across regions introduces latency, compliance risk, and consistency challenges that Unity Catalog’s architects chose to eliminate by making the region-to-metastore mapping a hard constraint.
What this means for multi-cloud and multi-region organizations:
AWS + Azure split environments. If your Databricks workspaces span AWS us-east-1 and Azure East US, you need two separate Unity Catalog metastores — one per cloud region. Catalog names must be globally unique within an account, but the metastores themselves are independent. Cross-metastore joins require Delta Sharing or explicit data movement; they cannot be done transparently in a single query.
Disaster recovery and metastore failover. Unity Catalog metastores are not user-managed for failover — Databricks manages metastore availability as part of the control plane SLA. Your DR planning should focus on the data layer (storage redundancy in the underlying cloud bucket) rather than the metastore layer. If a region goes down, Databricks restores metastore availability; your data persists independently in your cloud storage.
Delta Sharing as the cross-metastore bridge. When two business units operate separate Databricks accounts — each with its own metastore — Delta Sharing is the governed path for data exchange. The data never leaves the source storage account, but the recipient organization can query it through their own Unity Catalog metastore with their own access controls applied on top. This pattern is increasingly common in enterprise data mesh architectures where domains own their metastore and share selectively.
For most enterprise deployments, one metastore per cloud region is not a limitation but a feature — it keeps the access control boundary aligned with the network boundary and simplifies audit trails for regulators who want to know exactly where data lived and who could see it.
Databricks Metastore Best Practices The teams that run clean metastores follow a short list of rules with discipline. These are the ones that consistently separate audited, low-friction platforms from accidental sprawl.
Step 1: Align metastores with data residency. One metastore per operating region is a constraint, so use it as your residency boundary and keep regulated data inside its home region’s metastore.Step 2: Skip metastore-level root storage. Set managed storage per catalog instead, so each domain’s data stays physically isolated and no table silently lands in a shared default bucket.Step 3: Make a group the metastore admin. Individual ownership breaks when people leave, and a governance group keeps the role auditable.Step 4: Bind catalogs to workspaces. Use workspace-catalog binding to keep production catalogs invisible from development compute, which shrinks the blast radius of any mistake.Step 5: Share through Delta Sharing, not copies. Cross-region and cross-partner access belongs in shares, where grants and audit logs follow the data.Step 6: Keep names boring and predictable. Catalogs for domains or environments, schemas for stages, and no exceptions, because data governance best practices live or die on naming.Step 7: Watch the legacy catalog shrink. Track table counts in hive_metastore each month and treat any new object there as a regression to fix, not a habit to accept.Tooling helps enforce these rules, and the wider market of data governance tools can layer policy management on top. The metastore remains the enforcement point either way.
Automating Metastore Creation with Terraform The manual console workflow above works for a single proof of concept but does not scale to multi-region, multi-account enterprise deployments — and it can’t easily reproduce an exact configuration when you need to stand up a new region or rebuild a disaster recovery environment. One detail worth flagging before you automate: the storage root you configure at creation time is not something Databricks supports changing in place once catalogs and schemas are already writing to it, so get this right in your Terraform config on the first apply.
The databricks_metastore and databricks_metastore_assignment Terraform resources let you codify metastore creation, storage root configuration, and workspace attachment as part of your infrastructure-as-code pipeline:
resource "databricks_metastore" "this" {
name = "primary-us-east-1"
region = "us-east-1"
storage_root = "s3://uc-root-us-east-1/metastore"
force_destroy = false
}
resource "databricks_metastore_assignment" "prod" {
metastore_id = databricks_metastore.this.id
workspace_id = var.workspace_id
}Codifying this pays off the first time you need to stand up a metastore in a new region or reproduce the exact configuration for a disaster recovery environment — a manual console workflow is not something you want to be reconstructing from memory during an incident.
Troubleshooting Common Metastore Errors Metastore problems tend to look dramatic and resolve simply. These five cover most tickets platform teams see.
Step 1: “No metastore assigned for the current workspace.” The workspace is not attached to a Unity Catalog metastore. An account admin fixes it in the account console by assigning the workspace to the regional metastore.Step 2: METASTORE_DOES_NOT_EXIST from the API. The metastore ID in the request is wrong or belongs to another region. Confirm the ID with SELECT current_metastore(); and re-check the region.Step 3: Cross-region attachment refused. A workspace can only attach to a metastore in its own region. Create a metastore in that region and use Delta Sharing for anything that must span the two.Step 4: PERMISSION_DENIED on storage credentials. The IAM role or managed identity behind the credential lost its trust relationship or bucket rights. Re-validate the credential and confirm the external location path matches the granted scope.Step 5: Tables visible in hive_metastore but missing from a catalog. The tables were never upgraded. Run SYNC or the UCX workflows, then repoint consumers to the three-level name.Slow query starts after enabling Unity Catalog usually trace back to permissions checks on very wide grants rather than the metastore itself, and our Databricks performance optimization guide covers the tuning side. For error classes beyond governance, keep the broader Databricks troubleshooting guide bookmarked.
Talk to Kanerika
See a Governed Metastore Setup End to End
Walk through a reference Unity Catalog layout with Kanerika’s platform engineers, from regional metastore design to catalog bindings and Delta Sharing.
Schedule a Demo → How Kanerika Sets Up Governed Databricks Metastores Kanerika is a Databricks consulting partner that treats the metastore as the foundation of every lakehouse engagement, not an afterthought bolted on before go-live. Our Databricks practice pairs platform engineers with governance specialists so the account structure and the permission model land together.
A typical engagement runs in five stages. We assess the existing estate first, inventorying Hive tables, mounts, and access patterns the way UCX does but with business owners in the room. We then design the metastore and catalog layout against residency and domain boundaries, build the migration with SYNC and clone patterns wrapped in validation checks, wire the governance model of grants, bindings, and shares, and finally enable the client’s platform team to run it without us.
That governance depth comes from repetition at scale. For a global bank operating close to 9,000 branches, Kanerika built a unified data governance program over its centralized lakehouse , automating discovery, classification, and lineage across sources such as SAP, Oracle, and Dynamics 365. The program improved data classification accuracy by 72 percent, held the bank at zero data breaches, and reached 100 percent adherence to its compliance regulations.
Case Study
72% Better Data Classification for a Global Bank
Kanerika automated data discovery , classification, and lineage across a bank’s centralized lakehouse, improving classification accuracy by 72 percent with zero data breaches.
Read the Case Study → The pitfalls we watch for are consistent. Teams keep writing new tables into hive_metastore months after enabling Unity Catalog, hand the metastore admin role to a single engineer, or copy data across regions instead of sharing it. Our data governance services and data integration services teams close those gaps early, and our migration accelerators shorten the pipeline rework that a metastore cutover forces on jobs and dashboards.
Getting the Metastore Layer Right First The metastore is the smallest piece of a Databricks platform and the one with the longest consequences. One Unity Catalog metastore per region, catalogs shaped around domains, group-owned administration, and a deliberate migration off hive_metastore give every later decision a stable base. Rushed layouts do the opposite, leaking permissions and multiplying rework across every workspace they touch. If your estate still splits its tables between two metastore generations, talk to Kanerika about a governed migration plan that closes the gap without breaking a single pipeline.
Frequently Asked Questions What is a metastore in Databricks? A metastore is the top-level container that stores metadata and access permissions for data and AI assets in Databricks. It records table definitions, storage locations, and grants rather than the data itself. Unity Catalog uses one account-level metastore per region, replacing the legacy per-workspace Hive metastore that older deployments relied on.
How many metastores can you have in a Databricks account? Databricks allows one Unity Catalog metastore per region in each account. Every workspace in that region attaches to the same metastore, which gives all of them a shared namespace, permission model, and audit trail. Organizations operating in several regions create one metastore per region and connect them through Delta Sharing when data must cross boundaries.
How do I find my Databricks metastore ID? Run SELECT current_metastore(); in a notebook or SQL editor on any Unity Catalog-enabled cluster or warehouse, and the result returns the metastore ID for the attached workspace. Account admins can also open the account console, select Catalog, and view every metastore with its ID, region, and the workspaces assigned to it.
What is the difference between a metastore and a catalog in Databricks? The metastore is the top-level container, and catalogs are the first organizational layer inside it. A metastore holds many catalogs, and each catalog holds schemas that in turn hold tables, views, and volumes. Permissions can be granted at any of those levels, but storage credentials, external locations, and shares belong to the metastore itself.
Is metastore-level root storage required in Unity Catalog? No. Root storage at the metastore level is optional, and Databricks lets you create a metastore without it. Many platform teams skip it deliberately and assign managed storage locations per catalog instead, which keeps each domain’s data physically isolated and stops unrelated tables from accumulating in one shared default bucket.
How do I migrate tables from the Hive metastore to Unity Catalog? Assess the estate first, ideally with the UCX toolkit from Databricks Labs. Then create the target catalogs and external locations, upgrade external tables with the SYNC command, and move managed or DBFS-root tables with deep clone or CREATE TABLE AS SELECT. Finish by applying grants and repointing jobs to three-level table names.
Can one Databricks workspace be attached to multiple metastores? No. A workspace attaches to exactly one metastore at a time, and that metastore must be in the same region as the workspace. Account admins can reassign a workspace to a different metastore, but they cannot attach two at once. Cross-metastore access is handled through Delta Sharing rather than multiple attachments.
What happens to the hive_metastore catalog after enabling Unity Catalog? The legacy store stays available and appears in the namespace as a catalog named hive_metastore, so existing two-level references keep working. Its tables still lack Unity Catalog lineage, auditing, and fine-grained controls until you upgrade them. Databricks recommends migrating those tables over time and treating any new object created there as a regression.
