The Unity Catalog object model

One model for every governed asset

Governance fails when every kind of asset has its own rules: one permission system for tables, another for files, another for models, and a spreadsheet for everything else. Unity Catalog replaces that with one object model and one permission model. If you understand the model, every later lesson in this course is a variation on it.

In this lesson we walk through the objects, the namespace, the difference between managed and external, and the objects that sit above catalogs. We do not cover enabling Unity Catalog on a new account. That is a platform setup topic.

Securable objects

The Databricks documentation describes every governed asset as a securable object: an object on which you can grant permissions to users, service principals or groups. The same grant model applies to all of them.

Most objects you work with live in a three-level namespace: catalog.schema.object.

The documentation also lists services (model and MCP services) among the objects at the third level. Registered models are a kind of function in the privilege system, which is why you grant EXECUTE ON FUNCTION to let a group use a model.

Above the catalogs, directly under the metastore, sit objects that are not inside any catalog: storage credentials, external locations, connections (for Lakehouse Federation) and shares. They are shared across catalogs, so they deserve tighter control than a table.

Managed and external

Tables and volumes come in two kinds.

• Managed: Unity Catalog governs both the access and the lifecycle of the files. When you drop the table, the data goes too, after the retention behaviour of the platform.
• External: Unity Catalog governs access only. The files live in a location you manage, and dropping the table leaves the files.

Our default is managed objects for everything we create. Use external objects when another system must read or write the same files, or when a contract forces a storage location. External objects need a storage credential and an external location, and both are metastore-level objects that need careful grants.

Ownership

Every securable has an owner. Owners hold all privileges on the object, including the power to grant them. The owner is the most powerful position on an object, so it must never be a person.

• Make a group the owner of every catalog, schema, table and volume. A person leaves, a group stays.
• Use MANAGE sparingly. The MANAGE privilege lets a holder manage privileges, transfer ownership, rename and drop an object without being its owner. It is not part of ALL PRIVILEGES.
• Transfer deliberately. Ownership transfer is a single statement, which makes it easy and worth putting behind review:

ALTER TABLE prd_finance.gold.invoices OWNER TO `grp-uc-prd-finance-gold-owner`;

Designing the namespace

Names carry meaning and grants attach to them, so design the namespace before the first table exists. Our pattern:

• One catalog per environment and domain, for example dev_finance, test_finance, acc_finance, prd_finance. The environment prefix keeps an environment from touching another's data.
• One schema per layer or subject area, for example bronze, silver, gold, reference, sandbox.
• Names in lower case with underscores, with no spaces and no dates in names.
• One owner group per catalog and per schema.

Why not a single catalog for everything? Because permissions inherit downwards. A privilege on a catalog applies to every current and future schema in it. A catalog that spans domains forces you to grant on many schemas one by one, and one mistake exposes several domains.

-- Create the structure for one domain and environment. Run through the pipeline, not by hand.
CREATE CATALOG IF NOT EXISTS dev_finance;
CREATE SCHEMA  IF NOT EXISTS dev_finance.bronze;
CREATE SCHEMA  IF NOT EXISTS dev_finance.silver;
CREATE SCHEMA  IF NOT EXISTS dev_finance.gold;

Discovery commands you will use

You can inspect the model with plain SQL:

SHOW CATALOGS;
SHOW SCHEMAS IN dev_finance;
SHOW TABLES  IN dev_finance.gold;
SHOW GRANTS  ON SCHEMA dev_finance.gold;       -- who can do what on this schema
DESCRIBE EXTENDED dev_finance.gold.invoices;   -- owner, type (managed or external), location

SHOW GRANTS is the command you run most often when someone says "I cannot see the table". The answer is nearly always a missing USE CATALOG or USE SCHEMA on the path to it.

Tags and comments

Tables, columns and other objects accept comments and tags. Use them from the first day: a comment that states the purpose and data owner, and tags that classify the data, such as pii or confidential. In lesson 4 you will see how tags feed policies. Our privacy-by-design rule asks us to classify data before we load it, and tags are where that classification lives.

Common mistakes

• A person as owner. Access breaks when they leave.
• One catalog for all environments. A dev job can then write to production data.
• External tables by habit. You keep the storage lifecycle, and the risk, on your side.
• No comments and no tags. The catalogue becomes a list of names nobody can interpret.
• Granting on the table when the schema is the right level. Lesson 3 explains the pattern.

Summary

Every governed asset is a securable object with an owner and a place in the catalog.schema.object namespace. Use one catalog per environment and domain, one schema per layer, managed objects by default, and groups as owners. Metastore-level objects such as storage credentials and external locations need the tightest grants.

Next lesson: identity, the question of who is asking.