In Short: One Catalog, One Permission Model, Free Lineage
Unity Catalog is the layer that turned Databricks from a powerful compute platform into a governable data platform. It is a central catalog of every data and AI asset - tables, views, files (volumes), functions, ML models - addressed by a consistent three-level name (catalog.schema.object), secured by one SQL-style permission model, and instrumented with automatic lineage and audit across every attached workspace.
If you run Azure Databricks without Unity Catalog, you are running the platform as it existed years ago, and every governance conversation is harder than it needs to be.
The Model in Five Minutes
Namespace. Everything lives at catalog.schema.object. Catalogs draw the big boundaries - per domain, per environment, or both (finance_prod, finance_dev). Schemas group related objects. The discipline mirrors what domains do in Fabric: structure that matches ownership.
Securables and grants. Permissions are SQL grants on the hierarchy, inherited downward: grant USE and SELECT at catalog level and the analyst reads everything within; override where exceptions live. Row filters and column masks handle the fine grain - the Databricks counterpart of RLS in the Microsoft stack. Grants go to Entra-synced groups, never individuals, if you want the estate to survive staff turnover.
Lineage and audit for free. Because every workload runs through the catalog, lineage is captured automatically at column level: what produced this table, what consumes it, which model trained on it. Auditors and impact analysis get answers from telemetry, not from documentation nobody maintained.
Beyond tables. Volumes govern files with the same grants; models and functions register in the same catalog - one governance surface for the whole ML lifecycle rather than a separate registry with separate rules.
Why It Won
Two design choices did the work. First, centralisation with openness: one metastore governs many workspaces, but the data stays open Delta in your own storage, so governance does not become lock-in. Second, familiarity: the permission language is SQL grants, which every data professional already speaks, rather than a proprietary policy engine.
The result is that Unity Catalog became the assumed foundation - the place access reviews, lineage questions and audit requests go - much as Purview plays that role across the Microsoft estate.
The Fabric Angle
For Microsoft-centric organisations, the strategic development is that Unity Catalog and Fabric now compose. Fabric can mirror an Azure Databricks Unity Catalog into OneLake: the catalog's tables appear as mirrored data that Fabric engines, semantic models and Copilot consume, while Databricks remains the engineering system of record and Unity Catalog keeps governing the source. We cover the pattern in detail in Unity Catalog mirroring into Fabric.
Governance advice for that world: keep one source of truth per concern. Unity Catalog governs what engineering produces; Fabric and Purview govern what the business consumes; and the mirror is the explicit, audited seam between them - not a second place to configure the same permissions differently.
Sources and Further Reading
- Unity Catalog documentation
- Mirroring Azure Databricks Unity Catalog in Fabric
- What is Azure Databricks?
Frequently asked
Databricks' unified governance layer: a central catalog of data and AI assets - tables, views, volumes of files, functions, ML models - with one permission model, automatic lineage and audit logging across all workspaces attached to it.
Every asset is addressed as catalog.schema.object - for example finance.sales.orders. Catalogs are the top-level boundary (often per domain or environment), schemas group related objects, and the consistent naming is what makes permissions and discovery manageable at scale.
Standard SQL grants on securables, inherited down the hierarchy: grant on a catalog flows to its schemas and tables unless overridden. Row filters and column masks add fine-grained control. Groups from Entra ID keep grants manageable.
Automatic, column-level lineage captured from actual workloads: which jobs and queries produced a table, what downstream assets consume it, traced without anyone documenting anything. For impact analysis and audit questions it is one of the platform's strongest features.
Yes - this is the notable 2025-era development: Fabric can mirror an Azure Databricks Unity Catalog, making its tables appear in OneLake for Fabric engines and Power BI to consume, with Databricks remaining the system of record. It is the cleanest both-platforms pattern available.
