What you will be able to do
- Place the metastore, catalogs, schemas and data assets correctly in the Unity Catalog hierarchy
- Explain what each level of catalog.schema.object is used for and what it may contain
- Recognise the special catalogs Databricks provisions and which catalog is assumed when you omit one
- Distinguish tables from volumes as third-level objects
Key concept
Three-level namespace — Inside a Unity Catalog metastore, every governed data asset has a three-part name: the catalog that contains it, the schema inside that catalog, and the object itself (a table, view, volume, function or model). The same containment that names an object also organises its storage and access.
1.The metastore sits above the namespace, not inside it
Unity Catalog treats everything it governs as a securable object, and these objects form a hierarchy. The metastore is at the top. It holds the namespace but is not one of its three levels. Each metastore covers a single cloud region, so an organisation needs one metastore for every region it operates in. One metastore can be attached to several workspaces in the same region, so a catalog created in one workspace can be visible from the other workspaces that share its metastore.
Inside the metastore, data and AI assets use the name pattern catalog.schema.object. That covers tables, views, volumes, functions, models and services. Some securables are outside this namespace. Storage credentials, external locations, connections and shares control access to cloud storage and external systems, and they sit directly under the metastore. An external location never has a three-part name.
The hierarchy does more than name things. Databricks calls it the foundation for access control, because privileges are granted on these containers.
Checkpoint 1 of 5· Check yourself
Which of these objects does NOT have a catalog.schema.object name?
Views, volumes and functions live inside a schema. External locations sit directly under the metastore and are outside the three-level namespace, along with storage credentials, connections and shares.
“Other objects, such as storage credentials, external locations, connections, and shares, sit directly under the metastore.”Source: docs.databricks.com
2.Level 1: catalogs as units of isolation
The catalog is the first level of the namespace and the main way data is organised. It is the highest level, so Databricks advises making each catalog a logical unit of data isolation and a logical category of access. Grants made on a catalog then flow down to the schemas and objects inside it. In practice, catalogs often follow organisational units or software development lifecycle scopes. For example, you might have a production catalog and a development catalog, or one catalog for non-customer data and another for sensitive customer data.
The isolation can be physical as well as logical. Each catalog usually has its own managed storage location for managed tables and volumes. Catalogs without their own location can use a storage location set at the metastore level. Because there is one metastore per region, catalogs are also isolated by region.
You will also see catalogs you did not create. Standard catalogs are the ordinary kind. The table below covers the others.
| Catalog | What it is |
|---|---|
| Standard catalog | The typical catalog and the main unit for organising data objects |
| Foreign catalog | Used only for Lakehouse Federation. Mirrors a database in an external system so you can run read-only queries on it |
| hive_metastore | Shows the objects registered in the legacy Hive metastore, which is deprecated |
| Workspace catalog | Created by default in new workspaces and usually named after the workspace. All users of that workspace can access it by default |
| __databricks_internal | A reserved name. Holds internal state for features such as Lakeflow pipelines and AI/BI dashboards. Do not query, modify or delete it |
Every Unity Catalog workspace also has a default catalog. If a statement leaves out the catalog part of a name, Databricks uses the default catalog. In a workspace that was enabled for Unity Catalog automatically, the default is the pre-provisioned workspace catalog. A workspace admin can change it.
The workspace's default catalog, unless the session has switched to another one. In a workspace enabled automatically, that is the pre-provisioned workspace catalog unless an admin has changed the default.
Checkpoint 2 of 5· Exam question
A data analyst in the Databricks SQL editor runs `SELECT * FROM sales_orders;` and gets an error that the table cannot be found, even though the table exists and the analyst has been granted SELECT on it. No catalog or schema has been set for the session. What is the most likely cause, and how should the analyst fix it?
Correct answer: A — The query gives only a table name with no catalog or schema in context, so Unity Catalog cannot resolve it; the analyst should run `USE CATALOG` and `USE SCHEMA`, or reference `catalog.schema.sales_orders` directly.
- A. Unity Catalog's three-level namespace means an unqualified table name has no way to determine which catalog and schema to search unless a current catalog and schema are already set for the session. Running `USE CATALOG` and `USE SCHEMA`, or fully qualifying the reference, gives Unity Catalog the context it needs to locate the table.
- B. This is incorrect because Unity Catalog privilege grants take effect immediately and are not subject to a multi-minute propagation delay; the described symptom does not match how grants are applied.
- C. This is incorrect because Volumes are for unstructured files, not the described object; a genuine table that shows up in Catalog Explorer as a table is queryable with SQL SELECT, so this explanation does not fit the scenario.
- D. This is incorrect because Databricks SQL warehouses fully support the three-level `catalog.schema.table` namespace; removing the catalog prefix would not fix an unqualified-name resolution problem and is not required by the platform.
Sources3
3.Level 2: schemas organise a catalog
A schema is the second level of the namespace and always belongs to a catalog. It groups assets more finely than a catalog does. A schema usually covers one use case, project or team sandbox. Schemas can hold tables, views, volumes, models and functions, so they help with both access control and making data easy to find.
Two naming details matter. First, Databricks sometimes calls schemas databases, and CREATE DATABASE is an alias for CREATE SCHEMA. In Databricks, a database is the same level as a schema, not a level above it as in some relational systems. Second, every catalog automatically contains a reserved schema called INFORMATION_SCHEMA. It holds read-only metadata views that describe the catalog's objects, and it is separate from any schema you create.
Schemas are also part of the storage hierarchy. You can give a schema its own managed storage location to keep its managed tables and volumes physically separate from other schemas in the catalog. This is optional. If you don't set one, Unity Catalog uses the location of the next level up.
Checkpoint 3 of 5· Check yourself
A schema has no managed storage location, and neither does its catalog. Where is the data for a new managed table in that schema stored?
Storage falls back from schema to catalog to metastore. With no location on the schema or the catalog, the managed data goes to the metastore's location.
“data resides in the catalog's managed storage location (and if none is defined for the catalog, it resides in the metastore's managed storage location)”Source: docs.databricks.com
Sources4
4.Level 3: tables, views, volumes and other assets
The third level holds the assets themselves. Tables are collections of structured data in rows and columns. Views are saved queries over tables or other views. Functions are reusable logic that returns a single value or a set of rows. Models are AI models registered in Unity Catalog. Volumes are collections of data in cloud object storage. Volumes sit at the same level as tables, so a volume's full name is catalog.schema.volume.
The exam focuses on the difference between tables and volumes. Tables govern tabular data. Volumes govern non-tabular data in any format: structured, semi-structured or unstructured. Common uses include landing areas for raw files, staging locations for ingestion, and file storage for exploratory analysis. You can't turn one into the other. Files in a volume can't be registered as a table, because volumes are only for path-based access.
Tables and volumes can each be managed or external. For a managed object, Unity Catalog handles both governance and the storage lifecycle. For an external object, it handles governance only. Tables come in more types than volumes, as the table below shows. For most use cases, Databricks recommends managed tables.
| Table type | Description | Managed by | Write support |
|---|---|---|---|
| Managed | Databricks manages both metadata and data files | Unity Catalog | Yes |
| External | Metadata is in Databricks, data is stored externally | None or Unity Catalog | Yes |
| Foreign | References read-only data in external systems via federation | External system | No |
| Temporary | Session-scoped tables for intermediate data storage | None (session-scoped) | Yes |
Checkpoint 4 of 5· Match them up
Match each Unity Catalog object to its role in the hierarchy
Tap a term, then the definition that fits it.
Catalogs and schemas are the containers at levels one and two. Tables and volumes are third-level objects for tabular and non-tabular data.
“Volumes represent collections of unstructured data in cloud object storage.”Source: docs.databricks.com
Checkpoint 5 of 5· Exam question
A workspace has two catalogs, `prod` and `dev`, and both contain a schema named `sales` with a table named `orders` that have different row counts. An analyst needs to query only the orders table in the `prod` catalog. Which approach correctly and unambiguously targets that table?
Correct answer: A — Run `SELECT * FROM prod.sales.orders;`, since fully qualifying the query with the catalog, schema, and table name removes any ambiguity about which `orders` table is targeted.
- A. Supplying all three levels of the namespace removes any guesswork: Unity Catalog looks up `orders` inside `sales` inside `prod` directly, so it cannot resolve to the table in `dev` by mistake.
- B. This is incorrect because Unity Catalog has no rule that favors one catalog over another when a schema name collides; without a current catalog set, an unqualified two-part reference is ambiguous or resolves against whatever default is in effect, not necessarily `prod`.
- C. This is incorrect because setting the session catalog to `dev` makes `sales.orders` resolve inside `dev`, not `prod`, which is the opposite of what the analyst needs.
- D. This is incorrect because Unity Catalog does not track or use 'most recently created' as a resolution rule; a bare table name still requires a current catalog and schema to be set, and provides no guarantee of hitting `prod`.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.The metastore is the first level of the three-level namespace, so a full name is metastore.catalog.schema.Why is that wrong?
The metastore is the container above the namespace. The three levels are catalog, schema and object, and the catalog comes first.
Covered in The metastore sits above the namespace, not inside it
2.In Databricks, a database is a level above a schema, as in some relational systems.Why is that wrong?
In Databricks, database is another name for schema. CREATE DATABASE is an alias for CREATE SCHEMA, so both refer to the second level.
Covered in Level 2: schemas organise a catalog
3.Files dropped into a volume can be registered as a Unity Catalog table so they can be queried by name.Why is that wrong?
Volumes are only for path-based access. To work with tabular data by name, use a table.
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“A metastore is scoped to a single cloud region.”
↩︎ The metastore sits above the namespace, not inside it“The metastore is the top-level securable object. Within this metastore, your data assets live in a three-level namespace”
↩︎ Exam trap 1“Here, the catalog is the first layer of the three-level namespace.”
↩︎ Prediction“Volumes represent collections of unstructured data in cloud object storage.”
↩︎ Checkpoint - 2.https://docs.databricks.com/aws/en/data-governance/unity-catalog/access-control/permissions-conceptsOfficial docs
“This hierarchical structure also provides the foundation for access control in Unity Catalog.”
↩︎ The metastore sits above the namespace, not inside it“Within this metastore, data is represented as objects in a three-level namespace: catalog.schema.table.”
↩︎ Key concept - 3.https://docs.databricks.com/aws/en/catalogsOfficial docs
“Catalogs therefore often mirror organizational units or software development lifecycle scopes.”
↩︎ Level 1: catalogs as units of isolation“If you omit the top-level catalog name when you perform data operations, the default catalog is assumed.”
↩︎ Level 1: catalogs as units of isolation“If your workspace was enabled for Unity Catalog automatically, the pre-provisioned workspace catalog is specified as the default catalog.”
↩︎ Level 1: catalogs as units of isolation - 4.https://docs.databricks.com/aws/en/schemasOfficial docs
“Typically a schema represents a single use case, project, or team sandbox.”
↩︎ Level 2: schemas organise a catalog“Every Unity Catalog catalog automatically includes an INFORMATION_SCHEMA, a system-provided schema of read-only metadata views that describe the catalog's objects.”
↩︎ Level 2: schemas organise a catalog“For example, CREATE DATABASE is an alias for CREATE SCHEMA.”
↩︎ Exam trap 2“data resides in the catalog's managed storage location (and if none is defined for the catalog, it resides in the metastore's managed storage location)”
↩︎ Checkpoint - 5.https://docs.databricks.com/aws/en/volumesOfficial docs
“While tables govern tabular data, volumes govern non-tabular data of any format, including structured, semi-structured, or unstructured.”
↩︎ Level 3: tables, views, volumes and other assets“Volumes sit at the third level of the Unity Catalog three-level namespace (catalog.schema.volume)”
↩︎ Level 3: tables, views, volumes and other assets“You can't register files in volumes as tables in Unity Catalog.”
↩︎ Exam trap 3 - 6.
“Tables and volumes can be managed, where Unity Catalog handles both governance and the underlying file storage lifecycle, or external”
↩︎ Level 3: tables, views, volumes and other assets“Other objects, such as storage credentials, external locations, connections, and shares, sit directly under the metastore.”
↩︎ Checkpoint