07.2 Unity Catalog Metastore, Catalog & Schema
The most important Unity Catalog design decision is not how to create a table. It is how you design the governance hierarchy above the table.
The hierarchy is:
Metastore → Catalog → Schema → Table / View / Volume / Function / Model
This page explains what each boundary means, how they relate to workspaces and cloud storage, how permissions flow, and how an enterprise should decide where a dataset belongs.
Architect mental model: Metastore = regional governance boundary. Catalog = major data isolation/domain boundary. Schema = operational namespace and ownership boundary.
1. The three-level namespace
A Unity Catalog table is normally addressed as:
catalog.schema.table
For example:
procurement_prod.silver.purchase_order_item
The namespace is more than naming. It determines where governance is inherited, how users discover data, and which administrative boundary owns the object.
Databricks documents the metastore as the top-level Unity Catalog container, with catalogs containing schemas and schemas containing data and AI objects. Each metastore is scoped to a cloud region. See the Unity Catalog setup guide.
2. Metastore: the regional governance container
A metastore is the top-level container for Unity Catalog metadata and governance.
It registers information about:
- catalogs and schemas
- tables, views and volumes
- storage credentials
- external locations
- shares and other securable objects
- permissions and ownership
A metastore is associated with workspaces in a cloud region.
What the metastore is not
Do not think of a metastore as:
- a single database
- a physical S3 bucket containing every table
- a workspace
- a catalog
- a compute cluster
Instead:
Account
|
+-- Metastore (region)
|
+-- Catalog A
+-- Catalog B
+-- Catalog C
The metastore provides the governance context in which those catalogs exist.
Regional implication
A practical enterprise model is:
AWS us-east-1
└── UC Metastore US-East
├── finance
├── procurement
└── customer
AWS eu-west-1
└── UC Metastore EU-West
├── finance
├── procurement
└── customer
The two metastores are separate governance containers. Do not assume that a catalog in one region is automatically the same catalog in another.
See Create a Unity Catalog metastore.
3. Metastore administration
Unity Catalog has distinct account, workspace and metastore administration responsibilities.
| Role | Primary scope | Typical responsibility |
|---|---|---|
| Account admin | Account | Account-level configuration and metastore creation |
| Workspace admin | Workspace | Workspace users, workspace objects and workspace operations |
| Metastore admin | One metastore | Top-level UC governance and securables |
The metastore admin role is optional and is assigned by account administrators.
This separation matters because administrative authority is not the same thing as data access.
For example, a user with the ability to create a catalog does not automatically receive SELECT access to every table inside that catalog.
See Unity Catalog admin privileges.
4. Catalog: the first data isolation boundary
A catalog is the highest-level data container inside a metastore.
It contains schemas.
Metastore
└── Catalog
├── Schema
│ ├── Table
│ ├── View
│ └── Volume
└── Schema
Catalogs are excellent boundaries for:
- business domains
- environments
- regulatory zones
- ownership
- lifecycle
- access policies
- storage isolation
- data products
Example enterprise catalog design
One model is:
prod
├── finance
├── procurement
├── sales
└── supply_chain
Another is:
finance_prod
finance_dev
procurement_prod
procurement_dev
Neither is universally correct. The correct choice depends on whether domain, environment, regulatory scope or ownership is the stronger governance boundary.
5. Catalog design: domain-first vs environment-first
Pattern A — Domain-first
finance
├── bronze
├── silver
└── gold
procurement
├── bronze
├── silver
└── gold
Advantages:
- domain ownership is obvious
- data products stay together
- aligns naturally with data mesh
- fewer environment-specific namespaces
Risk:
- environment isolation must be designed carefully
Pattern B — Environment-first
dev
├── finance
└── procurement
test
├── finance
└── procurement
prod
├── finance
└── procurement
Advantages:
- strong environment boundary
- simple production isolation
- easy deployment promotion model
Risk:
- domain assets are spread across catalogs
Pattern C — Hybrid
prod_finance
prod_procurement
prod_customer
nonprod_finance
nonprod_procurement
nonprod_customer
This can be effective when security, compliance and deployment boundaries are strong enough to justify additional catalogs.
Rule: Do not create catalogs simply because you can. Create them when you need a meaningful governance, ownership, storage, lifecycle or isolation boundary.
6. Schema: the operational namespace
A schema is a container inside a catalog.
It is commonly used to organize tables, views, volumes, functions and related objects.
Example:
procurement_prod
├── bronze
│ ├── s4_po_header_raw
│ └── s4_po_item_raw
├── silver
│ ├── purchase_order
│ ├── purchase_order_item
│ └── supplier
└── gold
├── supplier_spend
├── category_spend
└── procurement_kpi
Schemas are useful for:
- medallion layers
- subject areas
- application boundaries
- data product versions
- teams
- lifecycle stages
Schema is not just a folder
A schema participates in:
- permissions
- ownership
- metadata
- managed storage
- object discovery
- lifecycle management
Therefore, naming schemas as arbitrary folders can create governance problems.
7. Catalog versus schema
| Question | Catalog | Schema |
|---|---|---|
| Major domain boundary? | Yes | Usually no |
| Strong access isolation? | Strong | Strong within a domain |
| Environment boundary? | Often | Sometimes |
| Business ownership | Excellent | Good |
| Medallion layer | Possible | Common |
| Table grouping | No | Yes |
| Storage override | Yes | Yes |
| Privilege inheritance | Yes | Yes |
| Three-level namespace | Level 1 | Level 2 |
A useful mental model is:
Catalog = "Who owns and governs this family of data?"
Schema = "How is that family organized and operated?"
8. Managed storage hierarchy
Managed table and volume storage can be controlled at different levels.
Metastore managed storage
|
+-- Catalog managed storage
|
+-- Schema managed storage
|
+-- Managed tables / volumes
A catalog-level managed location can override the metastore default.
A schema-level managed location can override the catalog-level default.
Think:
Schema location
↓ overrides
Catalog location
↓ overrides
Metastore default
This is a critical design point when designing S3 layouts.
Databricks requires the appropriate CREATE MANAGED STORAGE capability on an external location when specifying a custom managed storage location. See Create schemas and the Unity Catalog privileges reference.
9. Workspace attachment
A workspace is linked to a Unity Catalog metastore.
Databricks Account
|
+-- Workspace A ─┐
+-- Workspace B ─┼──> Regional Metastore
+-- Workspace C ─┘
|
+-- Catalogs
|
+-- Schemas
|
+-- Tables
Multiple workspaces can consume the same governed catalog structure when the architecture permits it.
This enables separate DEV, TEST and PROD operational workspaces while keeping governance centralized.
Workspace bindings can additionally restrict which workspaces can access particular catalogs and other governed resources.
10. Workspace binding versus permissions
These are different controls.
Permissions answer
What can this principal do?
Example:
procurement_analysts
└── SELECT on procurement_prod.gold.spend_daily
Workspace binding answers
Which workspaces can use this governed object?
Architecturally:
Access = Identity permission
AND
Workspace eligibility
Do not use workspace separation as a replacement for object-level authorization.
11. Privilege inheritance
Unity Catalog privileges are hierarchical.
Catalog
|
+-- Schema
|
+-- Table
+-- View
+-- Volume
+-- Function
For example:
GRANT USE CATALOG
ON CATALOG procurement_prod
TO `procurement_analysts`;
At schema level:
GRANT USE SCHEMA
ON SCHEMA procurement_prod.gold
TO `procurement_analysts`;
For data:
GRANT SELECT
ON TABLE procurement_prod.gold.spend_daily
TO `procurement_analysts`;
Privileges granted on catalogs and schemas can inherit to child objects according to the Unity Catalog privilege model. See the current privileges reference.
12. USE CATALOG and USE SCHEMA
A common authorization failure occurs because a user has table-level privileges but cannot resolve the namespace.
Typical access requires:
USE CATALOG
+
USE SCHEMA
+
appropriate table/view privilege
Example:
GRANT USE CATALOG
ON CATALOG procurement_prod
TO `procurement_analysts`;
GRANT USE SCHEMA
ON SCHEMA procurement_prod.gold
TO `procurement_analysts`;
GRANT SELECT
ON TABLE procurement_prod.gold.spend_daily
TO `procurement_analysts`;
This is why "I granted SELECT but the user still cannot query the table" is a common Unity Catalog troubleshooting scenario.
13. Creating catalogs
A catalog requires the appropriate metastore-level capability.
CREATE CATALOG IF NOT EXISTS procurement_prod;
A catalog can also specify a managed storage location when the architecture requires one.
See Create catalogs.
Naming convention
Prefer names that communicate ownership and lifecycle.
Good:
procurement_prod
finance_prod
customer_prod
shared_reference
Avoid:
test123
new_catalog
abc
data_final_final
For enterprise systems, naming should be documented and enforced through platform standards.
14. Creating schemas
Example:
CREATE SCHEMA IF NOT EXISTS procurement_prod.gold;
With a comment:
CREATE SCHEMA IF NOT EXISTS procurement_prod.gold
COMMENT 'Curated procurement analytics and business-ready datasets';
Schema creation normally requires USE CATALOG and CREATE SCHEMA on the parent catalog. See Create schemas.
15. Managing catalogs and schemas
Typical lifecycle operations include:
SHOW CATALOGS;
SHOW SCHEMAS IN procurement_prod;
DESCRIBE CATALOG procurement_prod;
DESCRIBE SCHEMA procurement_prod.gold;
Catalog and schema management includes operations such as:
- rename
- ownership changes
- comments
- tags
- permissions
- managed storage configuration where supported
- deletion
Treat destructive operations as governance operations, not ordinary SQL housekeeping.
See Manage catalogs and Manage schemas.
16. INFORMATION_SCHEMA
Unity Catalog exposes system metadata through INFORMATION_SCHEMA.
It is useful for:
- object inventory
- governance reports
- privilege audits
- automated documentation
- impact analysis
- platform observability
Example:
SELECT *
FROM system.information_schema.schemata;
The exact available views depend on the Databricks environment and current product capabilities. Use the current Information schema documentation when building automation.
Architect pattern: Use metadata APIs and INFORMATION_SCHEMA to automate governance rather than maintaining manually curated spreadsheets.
17. SAP / BW architecture mapping
If you come from SAP BW/4HANA, use this as a mental mapping rather than a one-to-one technical equivalence.
| SAP concept | Unity Catalog analogue |
|---|---|
| BW system boundary | Metastore / workspace architecture |
| Application/domain separation | Catalog |
| InfoArea / logical subject area | Schema |
| ADSO / table | Table |
| CompositeProvider / view | View |
| Authorization concept | UC privileges |
| HANA storage governance | UC storage governance |
The architectural similarity is the deliberate separation of ownership, namespace, authorization and physical data management.
18. Enterprise AWS example
Consider an enterprise with one AWS region, DEV/TEST/PROD workspaces, Finance and Procurement domains, and S3-based managed storage.
AWS Account
|
UC Metastore
us-east-1
|
+---------------+---------------+
| |
finance_prod procurement_prod
| |
+------+------+ +------+------+
| | | | | |
bronze silver gold bronze silver gold
| | | | | |
Delta Delta Delta Delta Delta Delta
______ governed S3 storage architecture ______/
|
+---------------+---------------+
| | |
DEV WS TEST WS PROD WS
The exact workspace binding model should be designed around who needs access to which catalog and why.
19. Procurement example
Suppose SAP S/4HANA produces purchase-order data.
Use:
procurement_prod
├── bronze
│ ├── s4_po_header_raw
│ └── s4_po_item_raw
├── silver
│ ├── purchase_order
│ ├── purchase_order_item
│ └── supplier
└── gold
├── supplier_spend
├── category_spend
└── procurement_kpi
Security can then align with business roles:
procurement_engineers
→ bronze + silver
procurement_analysts
→ gold
finance_analysts
→ selected gold datasets
This is usually easier to govern than putting all domains into one giant schema.
20. Common architecture mistakes
Mistake 1 — One catalog for everything
main
└── everything
This eventually becomes difficult to govern.
Mistake 2 — Catalog per table
This creates excessive governance overhead.
Mistake 3 — Schema as a security substitute
Schemas are useful security boundaries, but a catalog may be the better isolation boundary when ownership or regulatory controls differ substantially.
Mistake 4 — Environment embedded everywhere
Excessive dev/test/prod duplication can create unnecessary catalogs and migration complexity.
Mistake 5 — Ignoring storage boundaries
A clean namespace with poorly designed S3 isolation is not a complete enterprise architecture.
Mistake 6 — Granting permissions to individuals
Prefer groups and service principals for durable enterprise access models.
Mistake 7 — Confusing CREATE CATALOG with data access
Creating a catalog is an administrative capability. It does not mean the principal automatically has SELECT access to every object.
21. Architect decision framework
When deciding whether something should be a catalog or schema, ask:
- Does it need a distinct ownership boundary?
- Does it need distinct storage governance?
- Does it need independent workspace access?
- Is it only logical organization inside the same domain?
- Would splitting it create more governance than value?
Decision matrix
| Requirement | Catalog | Schema |
|---|---|---|
| Business domain | Strong fit | Possible |
| Regulatory isolation | Strong fit | Sometimes |
| Environment isolation | Strong fit | Possible |
| Medallion layer | Possible | Strong fit |
| Team organization | Possible | Strong fit |
| Separate managed storage | Strong fit | Strong fit |
| Workspace binding | Strong fit | Not the primary boundary |
| Object grouping | Weak | Strong |
22. Hands-on lab
Lab A — Build a namespace
Create:
lab_catalog
├── bronze
├── silver
└── gold
SQL:
CREATE CATALOG IF NOT EXISTS lab_catalog;
CREATE SCHEMA IF NOT EXISTS lab_catalog.bronze;
CREATE SCHEMA IF NOT EXISTS lab_catalog.silver;
CREATE SCHEMA IF NOT EXISTS lab_catalog.gold;
SHOW SCHEMAS IN lab_catalog;
Lab B — Create a table
CREATE TABLE IF NOT EXISTS lab_catalog.gold.daily_spend (
business_date DATE,
supplier_id STRING,
spend DECIMAL(18,2)
);
Then:
DESCRIBE TABLE lab_catalog.gold.daily_spend;
Lab C — Test privileges
Experiment with:
GRANT USE CATALOG
ON CATALOG lab_catalog
TO `data_analysts`;
GRANT USE SCHEMA
ON SCHEMA lab_catalog.gold
TO `data_analysts`;
GRANT SELECT
ON TABLE lab_catalog.gold.daily_spend
TO `data_analysts`;
Observe the difference between discovering an object, resolving a namespace, reading table data, and creating new objects.
23. Troubleshooting
Error: cannot use catalog
Check:
- workspace is attached to the correct metastore
- principal has USE CATALOG
- catalog is accessible from that workspace
- workspace binding is not blocking access
Error: cannot use schema
Check:
- USE CATALOG
- USE SCHEMA
- schema exists
- correct catalog/schema spelling
Error: cannot create schema
Check:
- CREATE SCHEMA on the parent catalog
- USE CATALOG
- Unity Catalog-compliant compute
- managed storage privileges if a custom location is specified
Error: table creation fails with storage permissions
Check:
UC privilege
+
External location
+
Storage credential
+
Cloud IAM
+
Workspace eligibility
The failure may be outside SQL authorization itself.
24. Interview questions
Basic
Q: What is a Unity Catalog metastore?
A regional top-level governance container for Unity Catalog metadata, securable objects and permissions.
Q: What is a catalog?
The highest-level data container inside a metastore.
Q: What is a schema?
A namespace inside a catalog that contains tables, views, volumes and other objects.
Intermediate
Q: What is the three-level namespace?
catalog.schema.table.
Q: Can multiple workspaces use one metastore?
Yes, subject to the workspace/metastore architecture and applicable bindings and permissions.
Q: Does CREATE CATALOG grant SELECT on the catalog's tables?
No.
Architect
Q: How would you design catalogs for a large enterprise?
Start with meaningful governance boundaries such as domain, regulatory zone, environment or ownership. Avoid both a single giant catalog and catalog-per-table fragmentation.
Q: Catalog or schema for Bronze/Silver/Gold?
Often schemas are a clean fit when the layers belong to the same governance domain. Separate catalogs may be justified when ownership, storage, compliance or workspace isolation differs materially.
Q: What is the relationship between UC permissions and workspace bindings?
Permissions answer what a principal can do; bindings constrain where a governed object can be accessed.
25. Production checklist
- metastore exists in the required region
- workspace-to-metastore relationships are documented
- account/workspace/metastore admin responsibilities are separated
- catalog boundaries have an explicit reason
- schema boundaries have an explicit reason
- naming conventions are standardized
- managed storage locations are intentional
- S3 prefixes/buckets align with governance boundaries
- groups are used instead of individual grants where possible
- USE CATALOG and USE SCHEMA are understood
- workspace bindings are documented
- ownership is defined
- metadata/API automation is considered
- dev/test/prod isolation is explicit
- cross-region strategy is documented
26. Final mental model
ACCOUNT
|
+-- METASTORE
| regional governance boundary
|
+-- CATALOG
| domain / isolation boundary
|
+-- SCHEMA
| organization / operational boundary
|
+-- TABLE / VIEW / VOLUME / FUNCTION / MODEL
data and AI assets
Remember the five dimensions:
Namespace → Where the object lives
Ownership → Who governs it
Privileges → What a principal can do
Binding → Which workspaces may use it
Storage → Where managed data physically lives
If you can reason across all five dimensions, you are no longer just creating Unity Catalog objects—you are designing the governance architecture around them.