Unity Catalog setup best practices for a new workspace

Summary

• Attach one metastore per region and reuse it. A metastore is the top-level container for a cloud region; adopt a single metastore per region with multiple catalogs, and plan the storage root carefully because it cannot be changed after creation.
• Design the three-level namespace deliberately. Organize catalog > schema > table/view/volume/function to reflect your organization, mapping catalogs to an environment, business unit, or domain (for example finance_dev, sales_prod).
• Federate identity and grant to groups. Use account-level groups with SCIM and SSO, grant permissions to groups (never individual users), and assign ownership of production catalogs and schemas to groups.
• Isolate environments with workspace bindings. Create catalogs per environment inside one metastore and bind production workspaces to only production catalogs; give each catalog its own managed storage for physical separation.
• Route all access through Unity Catalog. Default to managed tables, avoid hardcoded credentials and cluster-level data access, and rely on automatic auditing and lineage for governance and compliance.

Unity Catalog setup best practices for a new workspace

Unity Catalog provides a unified governance layer for all data and AI assets across the Databricks Platform. Setting it up well on a new workspace means deciding the metastore and namespace design up front, federating identity at the account level, and enforcing isolation so that grants, lineage, and audit logs are consistently applied. The practices below follow the recommended setup path.

Why these Unity Catalog setup practices matter

• Metastore setup. A metastore is the top-level container for all data assets in a cloud region, holding catalogs, storage credentials, and external locations. For most teams, adopt a single metastore per region with multiple catalogs rather than multiple metastores, unless regional isolation is a regulatory requirement. Plan the storage root carefully at creation because it cannot be changed afterward, and review default object-creation privileges before enabling automatic metastore assignment in production. See Manage your metastore.
• Three-level namespace and catalog design. Unity Catalog organizes data into a three-level namespace: catalog > schema > table/view/volume/function. Map catalogs to an environment, business unit, or domain; a widely adopted pattern is <business_unit>_<environment> (for example finance_dev, sales_stg, datascience_prod). Assign ownership of production catalogs and schemas to groups, and grant USE CATALOG and USE SCHEMA only to users who should see the data. See the Unity Catalog best practices.
• Identity federation and account groups. Manage identities centrally with account-level groups, and prefer account-level SCIM provisioning as the primary path. Grant permissions to groups rather than individual users, and create a standard group taxonomy such as <catalog>_readers, <catalog>_writers, pii_readers, and data_stewards. Avoid running workspace-level SCIM in parallel once account-level SCIM is active.
• Privilege model. Unity Catalog separates roles: an account admin creates and manages metastores and users; a metastore admin manages external locations, storage credentials, and connections and assigns catalog ownership; a workspace admin assigns a metastore to a workspace; and a data or catalog owner runs GRANT/REVOKE on objects they own. Being an account admin does not automatically make you a metastore admin.
• Environment isolation with workspace bindings. Create catalogs per environment (dev, staging, prod) inside a single metastore, and use workspace bindings so only certain catalogs are available in a given workspace, regardless of object-level grants. For strict isolation, bind production workspaces to only production catalogs.
• Managed storage and external locations. Default to managed tables, which Unity Catalog fully governs for lifecycle, location, and access. Give each catalog its own dedicated cloud storage container for physical separation. A storage credential encapsulates the cloud identity used to reach object storage, and an external location ties that credential to a specific path; use external tables only when storage must be shared with non-Databricks systems, and prefer external volumes for raw-data landing zones. See Connect to cloud object storage using Unity Catalog.
• Data isolation, auditing, and lineage. Unity Catalog supports isolation at several levels: admin delegation, workspace binding, storage separation, and access control, plus row filters and column masks for fine-grained security. Route every read, write, and execution through Unity Catalog so grants, lineage, and audit logs are enforced, and avoid hardcoded credentials or cluster-level data access that bypass governance.

Getting started

• Confirm a Unity Catalog metastore is attached to your workspace and Unity Catalog-compliant compute is available. See the setup checklist.
• Design your metastore and catalog architecture before creating objects.
• Add users and account-level groups, then create catalogs and schemas that map to your environments and domains.
• Review the Unity Catalog best practices and see Enterprise-scale governance patterns.

FAQs

How many metastores should a new deployment use?

Adopt a single metastore per cloud region with multiple catalogs. Use multiple metastores only when strict regional isolation is a regulatory requirement.

How should I organize catalogs and schemas?

Use the three-level namespace and map catalogs to an environment, business unit, or domain, following a pattern such as <business_unit>_<environment>. Assign ownership to groups, not individuals.

Should I grant permissions to users or groups?

Grant to groups. Use account-level groups with SCIM provisioning and a standard taxonomy such as readers, writers, pii_readers, and data_stewards.

How do I keep development and production data separate?

Create catalogs per environment inside one metastore and use workspace bindings so a workspace can see only its intended catalogs, giving each catalog its own dedicated storage.