Skip to main content
unity catalogdatabricks governancedata catalogdata access controldatabricks lineage

Databricks Unity Catalog: Complete Guide to Data Governance

Unity Catalog is Databricks' unified governance solution for data and AI assets across the lakehouse. It centralizes access control, audit, lineage, and discovery for tables, views, files, ML models, and AI assets across the workspaces of a Databricks account. Unity Catalog became generally available in August 2022, has been enabled automatically for every Databricks workspace created after November 8, 2023, and was open-sourced in June 2024.

This guide explains what Unity Catalog is, how its model works, and where it fits alongside the broader enterprise governance estate.

TL;DR

Unity Catalog is Databricks' centralized governance layer. It uses a three-level namespace - catalog.schema.table - to organize all data and AI assets, applies fine-grained access control via SQL GRANT/REVOKE, captures column-level lineage automatically for queries run on Databricks, records data access in an audit log, and powers cross-workspace discovery. Since June 2024 it is also available as an open-source project.

What Is Unity Catalog?

Before Unity Catalog, governance on Databricks meant duplicating ACLs across the legacy Hive metastore in every workspace, managing storage credentials manually, and assembling lineage from logs after the fact. Each workspace was its own island.

Unity Catalog replaces that fragmented model with a single account-level service that:

  • Holds metadata for every catalog, schema, table, view, function, model, and volume.
  • Enforces a unified permissions model with standard SQL grants.
  • Captures lineage automatically as queries run.
  • Records data access and system activity in an audit log system table.
  • Surfaces all governed assets through a searchable Catalog Explorer.

Unity Catalog is built into the platform as its default governance layer. It is also a prerequisite for Lakehouse Federation, for publishing listings in Databricks Marketplace, and for sharing data through the Databricks-hosted Delta Sharing server (now documented as OpenSharing).

Core Concepts

Unity Catalog organizes governance around several primitives:

  • Metastore - the top-level container, scoped to one cloud region. Databricks requires one metastore for each region in which an organization operates, and workspaces attach to the metastore in their region.
  • Catalog - the first level of the namespace. Catalogs typically map to a domain, environment, or business unit (finance, marketing, prod, dev).
  • Schema - the second level (formerly called database in Spark SQL terminology). Schemas group related tables and views.
  • Table - managed tables (Delta Lake by default, or Apache Iceberg), whose storage and lifecycle Unity Catalog handles, and external tables (Delta, CSV, JSON, Avro, Parquet, ORC or text), whose files stay in your cloud storage when the table is dropped.
  • View - saved SQL queries, including dynamic views with row- and column-level filtering, plus metric views that define business metrics once in YAML.
  • Volume - governed storage location for non-tabular files (PDFs, images, audio, ML model artifacts, raw data files).
  • Function - registered SQL or Python user-defined functions.
  • Model - registered MLflow models, governed alongside the data they consume and produce.
  • Storage credential + External location - Unity Catalog-managed authentication to external cloud storage. Storage credentials never need to be embedded in user code.

Three-Level Namespace

Unity Catalog's signature feature is the three-level namespace: every object is addressed as catalog.schema.object. This is a deliberate departure from the legacy Spark two-level (database.table) model.

Unity Catalog - Three-Level Namespace UNITY CATALOG - THREE-LEVEL NAMESPACE METASTORE - region-scoped CATALOG: finance SCHEMA: finance.raw tbl: invoices tbl: payments vol: receipts/ view: q3_kpis function: convert_currency() SCHEMA: finance.gold tbl: revenue_daily tbl: forecast_q4 model: ml.forecast_revenue CATALOG: marketing SCHEMA: marketing.events tbl: campaigns tbl: leads tbl: web_clicks view: mql_funnel SCHEMA: marketing.attribution tbl: touchpoints model: attribution_ml function: weighted_credit() Table View Volume Model Function
Click to enlarge

The third level matters because catalogs are administratively meaningful. They map to teams, environments, or domains, and they are the natural unit for top-level governance decisions: who owns this data, what region is it in, what permission scope applies?

Some example references:

  • finance.raw.invoices - raw invoice data in the finance catalog
  • marketing.gold.attribution_daily - production attribution table
  • main.mlmodels.churn_v3 - registered ML model

Access Control

Unity Catalog uses SQL GRANT and REVOKE statements. The same syntax works across SQL Editor, notebooks, jobs, and the API:

GRANT SELECT ON finance.gold.revenue_daily TO `data-analysts`;
GRANT MODIFY ON marketing.events.campaigns TO `marketing-engineers`;
GRANT USE CATALOG ON finance TO `finance-domain`;

Access can be granted on the metastore, a catalog, a schema, or an individual table, view, volume, function or model; columns are protected with masks rather than grants. Privileges propagate down: a grant on a catalog or schema applies to all its current and future child objects. Common privileges include SELECT, MODIFY, USE CATALOG, USE SCHEMA, EXECUTE (on functions), and READ VOLUME / WRITE VOLUME.

Row- and Column-Level Security

Beyond table-level grants, Unity Catalog enforces row filters and column masks via SQL functions. A row filter is a function that returns a boolean; a column mask is a function that transforms a value. Both attach to a table and are evaluated automatically on every query - including queries from BI tools. The documented syntax binds a mask to one column:

CREATE FUNCTION mask_pii(email STRING)
RETURN CASE WHEN is_account_group_member('analysts') THEN email
            ELSE 'REDACTED' END;

ALTER TABLE finance.raw.customers
ALTER COLUMN email SET MASK mask_pii;

For many tables at once, attribute-based access control (ABAC) policies attach at the catalog, schema or table level and apply row filters and column masks automatically to objects that carry the governed tags a policy targets.

Identity Federation

Users, groups and service principals are managed at the Databricks account level and can be provisioned through SCIM from an identity provider such as Microsoft Entra ID, Okta or OneLogin. Identity federation lets workspaces use those account-level identities, so a grant refers to the same principal in every workspace - no shadow user lists.

Data Lineage

Unity Catalog captures lineage automatically for queries run on Databricks through Databricks SQL or the Spark DataFrame interfaces, down to the column level when source and target are referenced by table name. There is no per-table setup: the table only has to be registered in a Unity Catalog metastore.

Lineage nodes cover tables and views, ML model versions, external assets and file paths, and the jobs and dashboards that read a table appear as its consumers. The Catalog Explorer surfaces lineage as an interactive graph; the same lineage is queryable through the system tables (system.access.table_lineage and system.access.column_lineage), which keep a rolling one-year window. For broader context on how lineage works, see data lineage and column-level lineage.

Captured lineage covers what runs on Databricks. Source systems upstream and BI tools downstream appear in the graph only when someone registers them as external lineage metadata. A cross-platform catalog such as Dawiso can hold Databricks lineage next to metadata from other platforms, and lineage across systems can be added by manual definition or import.

Audit and Discovery

Data access and system activity, such as reads, schema changes, grants and deletes, are recorded in the audit log system table system.access.audit. Databricks recommends querying that table; on AWS, audit logs can also be delivered as JSON files to an Amazon S3 bucket.

The Catalog Explorer is the discovery UI: a searchable, filterable browser over every governed asset, with descriptions, tags, lineage, owners, and previews. Tags can be applied to catalogs, schemas, tables, columns, views, volumes, functions and models, supporting common governance patterns like pii=true or domain=finance classifications. Catalog and schema tags are inherited by child objects only when ABAC policies are evaluated, and never down to columns.

Volumes for Unstructured Data

Volumes extend Unity Catalog governance to non-tabular files: documents, images, audio, video, ML model artifacts, raw payloads. Volumes are mounted at known paths (/Volumes/<catalog>/<schema>/<volume>/...) and accessed through the same SQL grant system that controls tables.

This matters most for AI workloads. Most enterprise AI requires both structured tables and unstructured documents - and before volumes, governing those two cleanly required two different systems. With volumes, a RAG pipeline can read PDFs, embed them, and write the resulting vectors back to a table, all under one consistent permission model.

Unity Catalog Open Source

On June 13, 2024, Databricks open-sourced Unity Catalog under the Apache 2.0 license, hosted by LF AI & Data, a foundation of the Linux Foundation. The open-source server implements the Iceberg REST Catalog API and is compatible with the Hive metastore API, so engines outside Databricks can read the tables it catalogs; Databricks named DuckDB among the launch supporters. The open-source project and the Databricks-managed service are separate implementations: features covered in this guide, such as automatic lineage capture and the system tables, are documented for the managed service.

How Dawiso Complements Unity Catalog

Unity Catalog governs the lakehouse extremely well. It does not, by itself, govern the rest of the enterprise: the operational systems that feed it, the BI tools that consume it, the business glossary that defines what "revenue" means, and the human stewardship workflows that decide who owns what.

The Dawiso Databricks connector reads Unity Catalog through its system tables and REST API. It ingests catalogs, schemas, tables, views, metric views, columns, volumes, functions and ML models, along with owners, tags, column masks, row filters and data classifications. Column-to-column lineage comes from system.access.column_lineage for activity inside a configurable lineage window (30 days by default), plus deterministic lineage for metric views (from their YAML) and dashboard datasets (from their SQL).

Dawiso then adds what lives outside the platform: business glossary definitions that are linked automatically wherever they appear in object descriptions, stewardship assignments, documented data quality checks together with the external engine that runs them, and lineage beyond Databricks, which can be extended by defining relations manually or importing them. The result is one governance picture: technical depth from Unity Catalog, business semantics and stewardship workflow from Dawiso.

Sources

See it in action

Data & Analytics Catalog

Create a unified view of your data assets and gain insights faster with automated data discovery.

A cookie a day keeps bad UX away.

We use cookies to personalize content, ads and to analyze our traffic. We also share information about your use of our site with our advertising and analytics partners who may combine it with other information that you've provided to them or that they've collected from your use of their services. By clicking "Accept All", you allow us to use cookies for analytics and ads via Google Tag Manager. You can also customize cookies.

Customize Consent Preferences

We use cookies to personalize content, ads and to analyze our traffic. We also share information about your use of our site with our advertising and analytics partners. Privacy Policy

Necessary cookies allow core website functionality such as user login and account management. The website cannot be used properly without strictly necessary cookies.

Functionality cookies are used to remember visitor information on the website, eg. language, timezone, enhanced content.

Analytics cookies are used to see how visitors use the website, eg. analytics cookies. Those cookies cannot be used to directly identify a certain visitor.

We use Microsoft Clarity to see how you use our website (including heatmaps and session replays) so we can improve it. By using our site, you agree that we and Microsoft can collect and use this data. See our Privacy Policy for details.

Advertisement cookies are used to identify visitors between different websites, eg. content partners, banner networks. Those cookies may be used by companies to build a profile of visitor interests or show relevant ads on other websites.