How to Structure Unity Catalog for Enterprise Governance

Unity Catalog is Databricks' unified governance layer. It is hierarchical: metastores, catalogs, schemas, and objects, with privileges inherited downward. Databricks' own best-practice guidance is explicit on the points that usually go wrong in enterprises: identity, groups, ownership, and isolation.

Identity first

Principals that receive Unity Catalog privileges should exist at the Databricks account, ideally provisioned from an identity provider. Databricks recommends avoiding workspace-level SCIM for Unity Catalog-enabled environments and managing groups in the IdP so they match organizational reality.

If you skip this, you will spend the next year granting tables to people who have already changed teams.

Catalogs are the isolation unit

Databricks describes catalogs as the primary unit of data isolation in the typical Unity Catalog model. Schemas add organization inside a catalog. A workable enterprise pattern is to let catalogs express a combination of environment and domain—for example, a production catalog per business domain, or an environment catalog with domain schemas—then stay consistent.

• Do not create a catalog per pipeline unless isolation truly requires it.
• Prefer catalog-level managed storage as the isolation boundary when you need storage separation.
• Bind catalogs to workspaces when the work environment and the data must share isolation requirements.
• There is one metastore per region; metastores are for regional isolation, not a default tenancy model.

Privileges that actually scale

USE CATALOG and USE SCHEMA are prerequisites to working inside a container; they are not SELECT. Databricks notes that this is how you prevent a table creator from sharing an object with people who should never have seen the schema.

BROWSE is different again: it allows metadata discovery without granting data access. Databricks recommends granting BROWSE on catalogs to a broad group (even all account users) so people can find data and request access. That only works if access-request destinations are configured. Discovery without a request path is how people invent extracts.

Reserve direct MODIFY on production tables for service principals. Humans should not be the runtime that writes production gold.

Ownership is a production control

The creator of an object is its first owner. Owners can grant privileges and transfer ownership. Databricks recommends assigning production ownership to groups and being sparing with ALL PRIVILEGES and MANAGE. Metastore admin is optional; do not create a superuser because the diagram had a box for one.

A structure you can explain

A catalog layout that cannot be explained in one page will not be followed. Write down: what a catalog means, what a schema means, who owns production objects, how a new domain is created, and how a human gets SELECT. Then implement that, including the awkward migration of workspace-local tables.

Governance that exists only in a policy PDF will lose to the next urgent pipeline. Governance that is the way tables are created will actually run.