Home / Databricks on Azure

Databricks on AzureHow-toAdvanced

Advisory: Unity Catalog across regions - one metastore per region, cross-region sharing and residency

Unity Catalog allows one metastore per region per account, so multi-region platforms need a plan for where data lives, how it's shared and how governance stays consistent. Decide which regions host which data, share across metastores with Delta Sharing, manage permissions as code, and plan DR separately from day-to-day sharing.

Deepak Bhardwaj2 min read

Applies toAzure Databricks accounts with workspaces in multiple Azure regions, Unity Catalog metastores, Delta Sharing (Databricks-to-Databricks)

The constraint

  • One Unity Catalog metastore per region per account.
  • Workspaces attach to the metastore in their region.
  • Catalogs and grants don't automatically appear in other regions' metastores.

Why multiple regions

Driver Design response
Data residency (e.g. EU, India) Keep regulated data in its region's metastore and storage
Users and sources spread globally Compute near the data; share results
DR Secondary region for recovery (see the Databricks DR post)

Patterns

Pattern How Fits
Regional hubs with shared gold Each region processes its own data; selected gold tables shared to other regions via D2D Delta Sharing Residency + global reporting
Central region, regional ingestion Regions ingest and anonymise, share to a central metastore Central analytics on aggregated data
Fully separate No sharing; separate platforms Strict separation requirements

Cross-region sharing

-- In the provider (e.g. centralindia) metastore
CREATE SHARE global_gold;
ALTER SHARE global_gold ADD TABLE prod_in.sales.daily_summary;
CREATE RECIPIENT westeurope_metastore USING ID '<recipient metastore sharing identifier>';
GRANT SELECT ON SHARE global_gold TO RECIPIENT westeurope_metastore;

-- In the recipient metastore
CREATE CATALOG shared_in USING SHARE `<provider sharing identifier>`.global_gold;
  • Data stays in the provider's storage; cross-region reads incur egress (check current pricing).
  • For heavy repeated reads, consider replicating to a local table on a schedule.
  • Share only what residency rules allow (aggregates, anonymised data).

Consistent governance

  • Manage catalogs, schemas, grants and tags as code (Terraform or bundles) applied to every metastore.
  • Same group names across regions from Entra ID (account-level groups span regions).
  • Same classification tags and policies (see the classification post).

Residency checks

  • Storage accounts for managed and external locations in the right region.
  • No cross-region external locations pointing at regulated data.
  • Audit cross-region share access.

Warning

Day-to-day sharing isn't DR. A share stops working if the provider region is down. DR needs replicated data and metadata in the secondary region.

Checklist

  • Regions and data placement decided by residency and users
  • Pattern chosen
  • Shares limited to allowed data
  • Egress cost and replication considered
  • Governance as code across metastores
  • DR designed separately

Related fixes