Databricks Unity Catalog Permissions Guide: GRANT/REVOKE, Inheritance & Securables

Permission control is the heart of Unity Catalog's data governance. Securable objects — catalogs, schemas, tables, views, functions, volumes, and more — are managed declaratively with GRANT/REVOKE statements that answer the question "who can do what". Unlike the legacy Hive Metastore (table ACLs), Unity Catalog supports hierarchical inheritance and unified management across workspaces.

This article walks through the overall permission model, GRANT/REVOKE syntax, a comparison table of privilege types, how inheritance works, the full list of securable objects, and field-tested best practices.

Permission Model Overview

The Unity Catalog permission model has three building blocks: securable objects (what is protected), principals (who receives the permission), and privileges (what action is allowed).

• Securable objects: Metastore / Catalog / Schema / Table / View / Function / Volume / External Location / Storage Credential
• Principals: users / groups / service principals
• Privileges: SELECT / MODIFY / CREATE TABLE / USE CATALOG / USE SCHEMA, and more

Permissions are managed with the ANSI SQL standard GRANT/REVOKE syntax. Databricks adds extensions such as USE CATALOG, USE SCHEMA, and CREATE VOLUME.

GRANT / REVOKE Syntax

-- Grant SELECT on a table
GRANT SELECT ON TABLE prod.silver.orders TO `data-analysts`;

-- Grant SELECT on every table under a schema (applied via inheritance)
GRANT SELECT ON SCHEMA prod.silver TO `data-analysts`;

-- Grant USE on a catalog (required to browse the namespace)
GRANT USE CATALOG ON CATALOG prod TO `data-analysts`;
GRANT USE SCHEMA ON SCHEMA prod.silver TO `data-analysts`;

-- Revoke a permission
REVOKE SELECT ON TABLE prod.silver.orders FROM `data-analysts`;

-- Inspect existing grants
SHOW GRANTS ON TABLE prod.silver.orders;
SHOW GRANTS TO `data-analysts`;

Wrap principal names in backticks. Backticks are also required when a group name contains a hyphen.

Privilege Types Comparison

Privilege Inheritance

In Unity Catalog, privileges flow automatically from higher-level objects down to lower-level ones. The hierarchy and inheritance flow look like this:

Metastore
 └── Catalog  ← GRANT SELECT ON CATALOG → applies to every Schema/Table/View beneath it
      └── Schema  ← GRANT SELECT ON SCHEMA → applies to every Table/View beneath it
           ├── Table  ← GRANT SELECT ON TABLE → this table only
           ├── View
           ├── Volume
           └── Function

Granting SELECT at the catalog level also applies to schemas and tables created later. If your goal is to keep permissions valid for future tables, granting at the schema or catalog level is the most efficient approach.

Unity Catalog has no DENY mechanism. To exclude a specific table, avoid granting at the catalog or schema level and design your grants per table instead.

Securable Objects Reference

Permission Design Best Practices

• Avoid granting directly to users; grant through groups instead (it integrates cleanly with SCIM provisioning)
• Do not forget to grant USE CATALOG and USE SCHEMA (SELECT alone cannot resolve names)
• Restrict MODIFY on production catalogs to ETL service principals only
• Give developers ALL PRIVILEGES on dev/staging catalogs and only SELECT on the prod catalog
• Periodically audit grants with SHOW GRANTS and revoke anything that is no longer needed
• Implement row- and column-level controls with dynamic views (using current_user() and is_member())

-- Row Level Security via a dynamic view
CREATE OR REPLACE VIEW prod.silver.orders_restricted AS
SELECT *
FROM prod.silver.orders
WHERE region = CASE
  WHEN is_member('apac-team') THEN 'APAC'
  WHEN is_member('emea-team') THEN 'EMEA'
  ELSE region  -- admins can read every region
END;

GRANT SELECT ON VIEW prod.silver.orders_restricted TO `all-users`;

The OWNERSHIP Concept

Every securable object has an owner. The owner holds every privilege on that object and can grant privileges to other principals. The user who creates a table becomes the default owner.

-- Change the owner
ALTER TABLE prod.silver.orders SET OWNER TO `data-engineering-team`;

-- Inspect the owner
DESCRIBE TABLE EXTENDED prod.silver.orders;
-- The Owner column shows the current owner

Key Points for the Exam

• USE CATALOG + USE SCHEMA + SELECT are all required to execute a query
• Privileges inherit downward (catalog → schema → table)
• DENY does not exist
• An owner effectively holds ALL PRIVILEGES on the object
• How to implement row- and column-level security with dynamic views
• How to inspect grants with the SHOW GRANTS syntax

Check Your Understanding

Frequently Asked Questions