← Platform Fundamentals & Architecture Review

▶ Listen · 8 min

Unity Catalog's object model

Unity Catalog (UC) is the governance layer: one place that knows what data exists, who may touch it, and where it came from. If you learned Databricks in the Hive metastore era, this replaces that entirely — and the old way is now explicitly labelled legacy.

The hierarchy

Account
└── Metastore                    ← one per region (see the hard constraint below)
    └── Catalog                  ← the primary unit of data isolation
        └── Schema  (= database)
            ├── Table            ← managed or external
            ├── View
            ├── Materialized view
            ├── Volume           ← governed files, not tables
            ├── Function
            └── Model

You address anything with three levels: catalog.schema.object. That's the "three-level namespace," and it's the most visible day-one difference from the old two-level database.table world.

SELECT * FROM prod_sales.finance.transactions;

Volumes deserve special attention

A volume governs files rather than tables — the place for CSVs waiting to be ingested, PDFs, images, model artifacts, anything non-tabular. Volumes are the sanctioned replacement for the patterns you'll see in old tutorials: DBFS mounts and raw storage paths.

This matters because DBFS root and DBFS mounts are deprecated, and — the part people miss — "New accounts are provisioned without access to these features" (DBFS docs, updated 2026-02-23).

So a tutorial that opens with dbutils.fs.mount(...) isn't merely dated. On a workspace created recently, it cannot work at all. Use volumes and external locations.

The one hard constraint

Memorize this sentence, because every multi-workspace and multi-region design decision follows from it:

"You can have only one metastore per region. All workspaces in that region share that metastore." — Unity Catalog best practices

Three consequences that turn up in architecture reviews constantly:

1. The catalog — not the metastore — is your isolation unit. You cannot give each team its own metastore in the same region. You give them their own catalogs. Separate prod from dev with catalogs (prod_sales, dev_sales), not with separate metastores.
2. Nothing crosses a metastore boundary implicitly. Grants don't. Lineage doesn't. If your business spans two regions, you have two metastores, and they know nothing about each other.
3. Cross-region sharing goes through OpenSharing (the product formerly called Delta Sharing — see lesson 5). That's the sanctioned bridge, and it's a deliberate export, not transparent access.

If you take one thing from this module into an architecture interview, take this.

Securables and privileges

Privileges inherit downward. Granting on a catalog reaches every schema and table inside it, now and in future.

GRANT USAGE ON CATALOG prod_sales TO `data-analysts`;
GRANT SELECT ON SCHEMA prod_sales.finance TO `data-analysts`;

Two traps worth internalizing:

• USE CATALOG / USE SCHEMA are required to traverse. A user with SELECT on a table but no USE on its parent catalog sees nothing. This is the number-one "but I granted them access!" support ticket.
• Ownership is not a privilege — it's a property. The owner can always grant, revoke, and drop. Orphaned objects owned by a departed employee's account are a real operational problem; own production objects with a group or service principal, never a person.

Beyond simple grants

The governance surface has grown considerably, and these are current as of 2026-07-30:

ABAC is the one to actually study — it appears by name in the May 2026 Associate exam guide, which means it's testable now. Module E4 covers it properly; A5 covers governance at scale.

The legacy path: Hive metastore

The per-workspace Hive metastore still exists but is officially "a legacy feature, and the instructions provided in this article represent legacy workflows" (docs, 2026-06-09).

New workspaces get a Unity Catalog workspace catalog by default. You'll still meet Hive metastore in brownfield migrations, where it appears as the hive_metastore catalog in the three-level namespace.

Honest gap: Databricks has published no hard end-of-life date for the Hive metastore. It's "legacy" and "deprecated," but if someone tells you it dies on a specific date, ask them for the link — I could not find one.

Check yourself

1. Write the full name of a table orders in schema raw in catalog dev_retail.
2. An analyst has SELECT on a table but gets "table not found." What's the most likely cause?
3. Your company operates in East US and West Europe. How many metastores, and how does a West Europe dashboard read an East US table?
4. Why shouldn't a production table be owned by a named individual?
5. A 2023 tutorial starts with dbutils.fs.mount(...). What do you do?

Answers

1. dev_retail.raw.orders
2. Missing USE CATALOG and/or USE SCHEMA on the parents. SELECT alone doesn't let you traverse to the object.
3. Two metastores — one per region, and that's forced, not chosen. Cross-region access goes through OpenSharing (formerly Delta Sharing); there is no transparent cross-metastore query.
4. Ownership is a property carrying full control including DROP. When that person leaves and their identity is deprovisioned, the object is orphaned. Own with a group or service principal.
5. Replace it with a Unity Catalog volume or external location. On a recently created account the mount API isn't merely discouraged — access isn't provisioned at all.

Teaching this section

• Draw the hierarchy as a tree and leave it on the board for the rest of the day. Every later topic — grants, lineage, sharing, isolation — points back at it.
• The single best exercise: give learners a SELECT grant without USE CATALOG and let them hit the error themselves. Ten seconds of confusion teaches this better than ten minutes of explanation.
• Watch for: people who've used Snowflake mapping metastore→account and catalog→database. The mapping is close enough to be dangerous. The one-metastore-per-region rule is where it breaks.
• Timing: 25 minutes presented, 15 for the grant exercise.