Unity Catalog governance best practices

The anti-pattern is granting per table because it feels fastest at that moment. Six months later nobody can explain why somebody has access to something, and cleaning up is riskier than leaving it alone.

That sounds like a relaxation and it is one, but it has a tail. Grants that used to do nothing because the matching usage privilege was missing are now active. Anyone who once handed out MANAGE generously on the assumption that it had no effect without USE CATALOG has gained administrators since, without anybody changing a thing. So walk through your MANAGE grants once and confirm they are intended.

The relaxation applies only to the metadata capabilities of MANAGE and of child privileges such as READ METADATA. Data access does not change: SELECT and MODIFY still require USE CATALOG and USE SCHEMA, even for someone holding MANAGE. That distinction is exactly what makes READ METADATA useful for auditors: read access to grants, row filters and masks, without ownership and without sight of the data itself.

Use them where the workload only does one thing, usually a service principal behind an ingest pipeline. Do account for the operations that require two privileges: INSERT OVERWRITE, INSERT REPLACE WHERE and dynamic partition overwrite need INSERT and DELETE together, and TRUNCATE falls under DELETE. Anything touching the schema still requires MODIFY, including schema evolution.

The most important agreement is not about granting but about revoking. MODIFY is a composite privilege and these three are its children, and they are managed independently. REVOKE MODIFY therefore does not remove a separately granted DELETE. Have your access review look at all four rather than only at MODIFY, otherwise it returns a clean result on a table where someone can still delete rows. See Revoking MODIFY does not remove a separately granted DELETE.

There is one situation where it does not work, and that is separation that must not mix. Think of somebody working for two clients, or a researcher on two studies. Until recently the only real answer was a second workspace or even a second metastore, with duplicate setup as the price. Since 19 August 2026 role-based access control is generally available: a user assumes a role (technically a group they hold Assume on), and that role's permissions replace their own set for the duration of the session.

Do not switch it on if you do not need it, because it costs work and it has edges. The most important one: every group in a workspace inherits from the users system group, so by default a role still sees everything shared with all workspace users. Anyone promising exclusive access trims that system group first. Also check whether your workloads can cope, because Lakeflow pipelines do not work under a role. See What Azure Databricks RBAC cannot do yet.

Skills did not get privileges of their own. Their contents sit in Unity Catalog managed storage, so you govern them with the volume privileges CREATE VOLUME, WRITE VOLUME and READ VOLUME, on top of the usual USE CATALOG and USE SCHEMA. Two consequences belong in your design. First, WRITE VOLUME alone is not enough to update a skill: always grant READ VOLUME alongside it. Second, and this weighs more, CREATE VOLUME is one privilege. Grant it on a domain schema so someone may publish skills, and that same person may also create ordinary volumes there.

So create a separate catalog for skills, with a schema per team or domain. That is what Databricks suggests as well, and it is the only way to assign authorship without handing out privileges on your data plane along with it. Before you let anyone publish, check that the schema sits under a standard catalog, so not under a foreign or federated one, and that it resolves to a managed storage location; without that location creation fails. Finally, bear in mind that workspaces under the compliance security profile may read skills but not create, update or delete them.

External tables remain necessary in three situations: data that already sits somewhere, data reached by path from tools outside Databricks, and formats managed tables do not support. Foreign tables are read-only references through Lakehouse Federation. Choose deliberately, because the type determines who does the maintenance.

Treat this as debt with a repayment schedule: an end date and a counter on the number of tables still left. Workspaces created after 9 November 2023 were automatically enabled for Unity Catalog by Databricks, older ones were not, so verify rather than assume.

Arrange read access explicitly for the account that scans or reports: SELECT on both tables, plus USE CATALOG on system and USE SCHEMA on system.access.

Since 26 August 2026, do not count on the literal SQL being included. Azure Databricks masks statement_text in system.query.history as <REDACTED> by default, does the same to query_text in the Query History API, and omits the keys in request_params in system.access.audit that contain a SQL definition. Only account admins and members of the account group databricks_pii_access see the text, and you have to create that group yourself.

That hits your evidence less hard than it sounds, provided you know where the boundary sits. The other columns and the other keys in request_params are unchanged, so who accessed what and when is still a query. What now requires a membership is what exactly was executed. So walk through your existing dashboards, alerts and jobs that lean on statement_text, because they do not fail but quietly deliver empty text. See Reading query text from system tables requires membership of a group that does not exist.