Unity Catalog Hierarchy and Volumes

Three levels, three jobs

Every data asset in Unity Catalog lives inside a three-level namespace: catalog.schema.object. Only three levels exist, so each one has to earn its place, and putting a boundary at the wrong level is the mistake that is expensive to undo.

A catalog is the top-level container and the primary unit of data isolation and organization. Catalogs usually represent a business domain, a security boundary, or a lifecycle environment such as development, testing, or production.

What makes the catalog the strongest boundary is what it can own:

Creating a catalog requires metastore administrator authority or the CREATE CATALOG privilege, which keeps the top of the hierarchy under deliberate control.

A new catalog is never empty. It arrives with two schemas created automatically: default, for general use, and information_schema, which holds metadata about the objects inside.

Workspace bindings deserve attention on production catalogs. By default a new catalog is reachable from every workspace attached to the metastore; restricting the bindings to production workspaces is what stops a development environment from querying or modifying production data by accident.

Schemas organize the interior

A schema is the second level of the namespace, inside a catalog. It groups related tables, views, volumes, and functions so that hundreds of objects do not sit in one undifferentiated space.

Schemas are usually organized in one of three ways:

One vocabulary note: in Databricks SQL, CREATE DATABASE is an alias for CREATE SCHEMA, so "database" and "schema" refer to the same second-level container.

Privileges that build the hierarchy

Creating something inside Unity Catalog always needs two kinds of privilege: permission to use the container you are working in, and permission to create that kind of object there.

Read the schema row carefully, because it is the shape of every other row: a schema is created inside a catalog, so the creator must be able to use that catalog and to create schemas in it. Privileges over files, over compute, or over a different level of the hierarchy do not substitute for either half.

Where managed data actually lands

Managed storage defines where Unity Catalog puts the data files of managed tables and volumes. It can be configured at the catalog level, at the schema level, or neither, and the resolution order is what matters in practice.

Configuring managed storage at either level requires an external location already governed by Unity Catalog and the CREATE MANAGED STORAGE privilege on it.

The override exists for a reason: it lets one schema keep its files in a separate storage account while the rest of the catalog stays where it is. Financial data that must live in a particular account, inside a catalog whose other schemas do not, is exactly the case it answers.

Without a schema-level location nothing breaks; the schema simply inherits, which keeps administration simpler when physical separation is not required.

The same reasoning scales up to the catalog. A production catalog that needs dedicated storage and access from production workspaces only is created with a managed storage location and restricted workspace bindings — the schemas inside then inherit that storage unless one of them overrides it. A single volume, a file-name prefix, or a schema without a parent catalog cannot express any of that: only the catalog carries storage, policy, and bindings at the top level.

Design a catalog for production isolation

Put the previous pieces together on one requirement: production needs dedicated storage, only production workspaces should reach it, and managed objects in its schemas should inherit that storage unless a schema overrides it.

The design that satisfies all three is a catalog created with a managed storage location and with its workspace bindings restricted. Storage, access policy, and workspace reach are all catalog-level properties, and schema-level overrides remain available for the exceptions.

The alternatives fail on structure rather than on detail:

• A single volume with a read grant governs files, not a storage boundary for tables and schemas.
• A schema cannot exist without a parent catalog, and it has no workspace bindings of its own.
• A file-name prefix inside a catalog open to every workspace communicates a boundary while enforcing nothing.

Volumes govern files

Tables govern structured data. Volumes govern everything else: a volume is the Unity Catalog object for files in cloud object storage, of any format — CSV, JSON, Parquet, images, audio, machine learning artifacts.

A volume sits at the third level of the namespace, catalog.schema.volume, which means files receive the same governance model as tables instead of a parallel one built out of storage credentials.

That is worth contrasting with the machinery that only looks similar. A SQL warehouse, an instance pool, or a compute policy configures or supplies compute; none of them governs a file. The volume is the object that gives a file an identity inside the catalog hierarchy.

The path follows the namespace

Files in a volume are reached through one path format, and it mirrors the namespace exactly:

/Volumes/<catalog>/<schema>/<volume>/<path>/<filename>

So a file called orders.csv, in a volume named landing, inside the schema bronze of the catalog sales, is /Volumes/sales/bronze/landing/orders.csv. The order never changes: catalog, then schema, then volume, then the path inside it.

This works across Spark, pandas, SQL, and file utilities without cloud storage credentials or connection strings in the code. Nothing else is a valid prefix — paths do not start with the words for schemas or catalogs — and reordering the three names points at a volume that does not exist.

Managed or external volume

Both kinds of volume are accessed the same way and permitted the same way. What differs is who owns the storage lifecycle, and it shows up when the volume is dropped.

Choose a managed volume when the work happens inside Azure Databricks and simple, platform-controlled storage is what you want.

Choose an external volume when another system must keep using the same location: a legacy application writing files, or models consumed by an external service. The volume adds Unity Catalog governance on top of storage that already exists, without taking over its lifecycle.

That combination answers a specific and common requirement — a legacy application and Azure Databricks share model files at an existing path, governance must be added, and dropping the Unity Catalog object must not delete the files. An external volume over that path satisfies every part of it.

A managed volume would move the files into schema storage and put their deletion under Unity Catalog's control, which is precisely what the requirement forbids.

Volume privileges apply to the whole volume

Working with a volume needs privileges at every level above it, plus the right privilege on the volume itself.

Grants also cascade: read access given at the catalog level reaches the volumes inside it, which makes broad policies easy and specific restrictions deliberate.

One limitation shapes the whole design: volumes do not support folder-level or subdirectory-level access control. A grant applies to the entire volume, so there is no way to open one directory to a group and close the next one.

The consequence is a rule worth internalizing: when two sets of files need different readers, create two volumes. Each volume becomes its own security boundary while both keep the standard governed path.

Attempts to work around it do not hold. Granting read on selected folders is not supported; using file names or their capitalization as a boundary enforces nothing; and a write privilege is not a substitute for read access, nor is an external location a place to attach per-group reader permissions for volume files.

Key takeaways

• The namespace is catalog.schema.object: the catalog is the top-level isolation boundary with its own storage, access policies, and workspace bindings, and it arrives with default and information_schema.
• A schema is the second level and groups tables, views, volumes, and functions; creating one requires USE CATALOG and CREATE SCHEMA, and CREATE DATABASE is an alias for CREATE SCHEMA.
• Managed storage can sit at catalog or schema level: the schema location overrides the catalog's, and without either, managed objects fall back to the metastore default.
• A volume governs files at catalog.schema.volume, reached through /Volumes/<catalog>/<schema>/<volume>/<path>/<filename>; managed volumes hand their lifecycle to Unity Catalog, while dropping an external volume leaves the files in place.
• READ VOLUME reads and lists, WRITE VOLUME modifies, and because permissions cover the whole volume, different access requirements mean separate volumes.