Key takeaways
✓Unity Catalog is Databricks' centralised governance layer, controlling who can access what data, models, and AI assets across every workspace in your organisation.
✓It uses a three-level namespace (catalogue, schema, object) to organise assets consistently, regardless of cloud provider or business unit.
✓Permissions are set once at the metastore level and flow down automatically, replacing the inconsistent, workspace-by-workspace access controls that create audit headaches.
✓Unity Catalog governs more than tables: files, ML models, dashboards, and AI agents all fall under the same permission model.
✓Teams in regulated industries (financial services, healthcare, government) gain the most immediate value, but any organisation running multiple Databricks workspaces will find it difficult to manage access at scale without it.
What is Databricks Unity Catalog?
Databricks Unity Catalog is the centralised governance layer for the Databricks Lakehouse Platform. It gives data teams a single place to define who can access what data, track where that data came from, and audit what has been done with it, across every workspace in an organisation.
Before Unity Catalog, Databricks users managed access controls inside individual workspaces. A large organisation might have dozens of workspaces, each with its own permissions, its own metadata, and no consistent view across all of them. A data engineer in one workspace had no reliable way to discover a dataset owned by another team. A compliance officer had no single audit trail covering the whole environment. Unity Catalog was built to close that gap.
It sits one level above the individual workspace. Once a metastore (the top-level Unity Catalog container) is attached to your workspaces, the same data assets, the same permissions, and the same audit logs are visible across all of them. You define access once and it applies everywhere.
The core promise of Unity Catalog
One set of policies, one audit trail, and one searchable catalogue, shared across every Databricks workspace in your organisation. That consistency is what makes enterprise-scale governance tractable.
Unity Catalog governs more than tables. It covers structured data, unstructured files, machine learning models, notebooks, dashboards, and, increasingly, the AI agents and functions built on top of your data. If your team is moving toward AI-driven workflows, as many Australian data teams are, governance of models and features matters just as much as governance of the underlying tables. More on that in a later section.
For teams working across the Databricks Lakehouse, Unity Catalog is the mechanism that turns a powerful but loosely controlled environment into something an enterprise risk or compliance function can actually work with.
How does Unity Catalog organise your data?
Unity Catalog uses a three-level namespace: catalog, schema, and table. Every data asset lives at an address that looks like catalog.schema.table, and that address is how permissions, lineage, and search all hang together.
Think of it this way:
A catalog is the top-level container, roughly equivalent to a database server or a business domain. You might have one catalog for finance, one for operations, one for a specific product line.
A schema (also called a database in some systems) sits inside a catalog and groups related objects together. A finance catalog might contain schemas for accounts-payable, reporting, and raw ingestion.
A table, view, volume, or model lives inside a schema. This is the actual data asset your analysts and engineers work with day-to-day.
Before Unity Catalog, Databricks workspaces each managed their own metadata independently. A table in one workspace was invisible to another, and permissions set in one place had no bearing anywhere else. The three-level namespace changes that: because every asset has a globally unique address, you can grant permissions, run audits, and track lineage across your entire organisation from a single control plane.
Why the structure matters for governance
The three-level hierarchy is not just organisation for its own sake. It is the foundation that makes cross-workspace access control, data lineage tracking, and regulatory audit trails possible. Without a consistent address for every asset, none of those capabilities can work reliably.
The practical value shows up quickly in regulated environments. If a compliance officer needs to confirm that only approved teams can read customer PII (personally identifiable information), they can inspect permissions at the catalog or schema level and have that answer immediately, rather than hunting through individual workspace ACLs (access control lists). For Australian organisations navigating the Privacy Act or sector-specific obligations, that kind of visibility is not a nice-to-have.
It is also worth noting how volumes fit in. Unity Catalog extended the namespace beyond structured tables to include unstructured files stored in cloud object storage. A volume lives at catalog.schema.volume_name, which means raw CSV files, PDFs, or model artefacts get the same governance treatment as a polished SQL table. That matters as teams start building AI applications on the lakehouse, where the boundary between data and AI assets is increasingly blurred.
How do Databricks Unity Catalog permissions work?
Unity Catalog uses a standard GRANT and REVOKE model, the same SQL syntax that database administrators have used for decades. What makes it practical at enterprise scale is that permissions cascade down through the three-level hierarchy. Grant a user USE CATALOG on a catalog, and they can see it exists. Grant SELECT on a schema, and that right flows to every table within it. You do not need to touch hundreds of individual tables every time someone joins the team.
The objects in the permission chain, from broadest to narrowest, are:
Metastore (the top-level container, one per region)
Catalog
Schema
Table, view, volume, or function
Permissions set higher up apply unless a more specific rule overrides them lower down. This inheritance is intentional: it lets you define coarse access for most users at the catalog or schema level, then carve out finer controls only where you genuinely need them.
Principals: who you grant to
Unity Catalog recognises four types of principal: individual users, service principals (automated workloads, pipelines, scheduled jobs), groups, and account-level groups that span multiple Databricks workspaces. In practice, most teams manage access through groups rather than individuals. Assigning access to a group means you only update one record when someone moves teams, rather than hunting through table-by-table grants.
Identity federation
Unity Catalog connects to your organisation's identity provider, typically Azure Active Directory, AWS IAM, or a SCIM-compatible directory. This federation means the same user identities and group memberships that govern your broader enterprise access also govern data access in Databricks. A new starter added to the right Azure AD group at onboarding gets the appropriate catalog access automatically. An employee who leaves and is disabled in Active Directory loses access to the lakehouse at the same moment.
Federation closes the gap between HR and data access
Without identity federation, data access and employment status drift apart. A user disabled in Active Directory but still holding active table grants is a compliance finding waiting to be written up.
What a typical permission set looks like
For a mid-market finance team, the setup might look like this:
Principal | Object | Privilege |
|---|---|---|
|
|
|
|
|
|
|
|
|
| Entire metastore |
|
|
|
|
The auditors row is the interesting one. That group gets read access to one sensitive table without any visibility into the rest of the schema. The grant is narrow, it is auditable, and revoking it is a single command.
REVOKE and the audit trail
Every GRANT and REVOKE operation is logged in the Unity Catalog audit log. For teams operating under regulatory frameworks, that log is the evidence your access review needs. You can query it directly to answer the question "who had access to this table, and when did it change?" without relying on tribal knowledge or a spreadsheet maintained by whoever remembers.
The combination of cascading grants, federated identity, and a clean audit trail is what makes Databricks Unity Catalog permissions genuinely useful for governance rather than just theoretically complete.
What does Unity Catalog govern beyond tables?
Unity Catalog governs far more than tables and views. That broader scope is what makes it relevant to teams building AI products, not just teams managing data warehouses.
Volumes let you store and govern unstructured files (PDFs, images, audio) inside the Unity Catalog namespace alongside your structured data. A volume sits in the same three-level hierarchy as a table, so the same permission model applies. A compliance team can restrict access to raw document ingestion folders the same way they restrict access to a sensitive customer table.
Registered models bring your MLflow machine learning models under catalog governance. Instead of a model floating in a workspace experiment, it lives at a path like prod.risk_models.credit_scoring_v3. You can grant EXECUTE permission to the serving endpoint that needs it and deny it to everyone else. Version history, lineage, and access control travel with the model. For regulated industries, this matters: you need to know who accessed which version of a model and when.
User-defined functions (UDFs) are registered and governed the same way. A data engineering team can publish a standardised masking function for PII fields and grant analysts EXECUTE without exposing the underlying logic or the raw data it protects.
Governance follows the asset, not the location
Because models, functions, volumes, and tables all live in the same catalog hierarchy, one permission framework covers your entire data and AI estate. You are not stitching together separate access-control systems as your stack grows.
Delta Sharing is worth calling out separately. It is an open protocol that lets you share live data with external parties, including organisations running different platforms entirely, without copying the data or giving them access to your Databricks environment. Unity Catalog manages what is shared, with whom, and for how long. For Australian organisations sharing data with partners, subsidiaries, or regulators, this is a meaningful capability: the data owner retains control even after the share is established.
Taken together, these capabilities mean Unity Catalog can serve as the single governance layer for a Databricks Lakehouse that runs both analytics workloads and AI pipelines. That convergence is exactly where most enterprise data platforms are heading.
Who actually needs Unity Catalog?
The short answer: more roles than most teams expect when they first set it up.
Data engineers are typically the first to work with Unity Catalog directly. They register tables, define schemas, set up Delta Sharing for cross-workspace access, and write the pipelines that land data into governed locations. For a data engineer, Unity Catalog is the difference between building on a shared, auditable foundation and managing a tangle of per-workspace permissions that nobody fully understands.
Platform and infrastructure teams own the metastore setup, the storage credentials, and the external location configurations that Unity Catalog sits on top of. They are the ones who decide how many metastores to run, how workspaces attach to them, and what the account-level admin structure looks like. Get this wrong early and you are refactoring governance architecture under pressure later.
Data and AI governance leads (sometimes sitting in risk or compliance functions) rely on Unity Catalog for the audit logs and lineage trails that regulators and internal audit teams ask for. In regulated industries like financial services and healthcare, being able to show exactly which process read a sensitive table, and when, is not a nice-to-have. Unity Catalog produces that trail automatically; without it, you are reconstructing it by hand.
Analytics engineers and senior analysts interact with Unity Catalog primarily through permissions. They need access to the right schemas without being able to see data they should not. Unity Catalog makes that boundary enforceable rather than advisory.
Compliance teams often get involved late
In many organisations, risk and compliance stakeholders only engage with Unity Catalog after an audit question surfaces that the team cannot answer cleanly. Building them into the governance design from the start is considerably cheaper than retrofitting it.
Business stakeholders rarely touch Unity Catalog directly, but they benefit from it. When a Databricks Genie query returns results, the data behind it has already been filtered by the permissions Unity Catalog enforces. The business user sees the data they are allowed to see, nothing more.
The teams that genuinely do not need deep Unity Catalog knowledge are individual contributors who only consume published reports or dashboards. For everyone who touches the data layer itself, some working knowledge of how Unity Catalog permissions flow is worth having. That is especially true in Australia, where AI regulation and data obligations are tightening and the expectation that organisations can demonstrate data lineage and access controls is becoming harder to ignore.
Frequently asked questions
Does Unity Catalog cost extra on Databricks?
Unity Catalog is included in Databricks at no additional licence fee. You pay for the compute you use to run queries and pipelines; the catalog layer itself does not add a separate charge. That said, enabling Unity Catalog does introduce some infrastructure requirements, such as an external storage location in your cloud provider, which carry their own storage costs. For most teams, those costs are negligible compared to the governance value.
What is a metastore, and do I need to create one per workspace?
A metastore is Unity Catalog's top-level container: it holds all the metadata about your data assets and the access policies that govern them. You create one metastore per region in your cloud account, and then attach as many Databricks workspaces to it as you need. This is a deliberate design choice. A single metastore covers your entire organisation in a region, so permissions and lineage are consistent across every team and workspace rather than duplicated and potentially contradictory.
What happens to my existing Hive metastore tables?
Every Databricks workspace has historically used a local Hive metastore, a legacy component inherited from the open-source Spark ecosystem. Those tables still work after you enable Unity Catalog; they appear in a special hive_metastore catalog. You can continue using them, but they sit outside Unity Catalog's governance controls. To bring them under centralised permissions and lineage, you migrate them to a Unity Catalog-managed catalog, which Databricks provides tooling to do incrementally. There is no hard deadline forcing an immediate migration, but leaving tables in Hive metastore means they remain an ungoverned blind spot.
Is Unity Catalog sufficient for regulated industries like financial services or healthcare?
Unity Catalog provides the access control, lineage, and auditability infrastructure that regulated environments require. Whether it is sufficient depends on what your compliance framework specifically demands. For example, column-level masking and row-level filters let you enforce data-minimisation requirements; audit logs exportable to your SIEM (security information and event management) tool support evidence-gathering for regulators. In practice, teams in Australian financial services and healthcare use Unity Catalog as the data governance layer and complement it with their organisation's broader security controls. Unity Catalog handles what happens inside the lakehouse; network controls, identity providers, and data classification tools handle the perimeter.
Can Unity Catalog govern AI models and features alongside tables?
Yes. Unity Catalog stores and versions machine learning models, and it tracks feature tables used in model training. You can apply the same permission model you use for data to models: controlling who can read, execute, or modify a registered model. This matters because a model trained on sensitive data inherits some of the sensitivity of that data. Treating models as governed assets in the same catalog as your tables, rather than as artefacts living outside your governance perimeter, closes a gap that many teams only notice when an audit or incident forces the question.
Building Unity Catalog skills on your team
Understanding Unity Catalog conceptually is one thing. Configuring metastores, writing correct privilege grants, setting up attribute-based access policies, and connecting external locations to your storage accounts are all hands-on tasks that take practice to get right.
Most teams hit the same sticking points: permissions that look correct but silently block downstream queries, Unity Catalog lineage that does not capture what the team expected, or a metastore architecture that made sense at setup but becomes a constraint as the organisation grows. These are not documentation problems. They are gaps that structured training closes faster than trial and error.
Where skills gaps show up in Unity Catalog deployments
The most common issues are not conceptual misunderstandings. They are misconfigured privilege hierarchies, storage credentials set at the wrong scope, and data products registered in Unity Catalog that nobody has been trained to find or query.
Better People delivers Databricks training in Australia built around your team's actual environment. That means working through Unity Catalog configuration against your own metastore, not a generic sandbox, and building Databricks Unity Catalog permissions models that reflect how your organisation actually separates access across teams, environments, and regulatory boundaries.
Training can be scoped to a single intensive session for a platform team, or structured across a broader rollout that brings data engineers, analysts, and data owners up to a working level together. For regulated industries, sessions can be aligned to the specific access control and audit requirements your team is accountable for.
The Databricks training pillar covers the full picture if you want to understand how Unity Catalog training fits alongside other Databricks capability-building, from lakehouse fundamentals through to pipeline development and certification preparation.
Is your team's Unity Catalog setup as secure as you think?
We'll talk through your current Unity Catalog configuration, where the access control gaps typically appear, and what a practical training engagement would look like for your team.
