Unity Catalog is the governance layer built into Azure Databricks for data and AI assets. It provides centralized access control, discovery, lineage, auditing, classification, quality features, and a three-level namespace across workspaces. In current Azure Databricks, Unity Catalog sits under tables, views, volumes, functions, models, and AI services so the same governance model can span both data engineering and AI workloads.<\/p>\n
Within Microsoft Fabric Engineering<\/a>, Unity Catalog matters because many enterprise data platforms use Fabric and Azure Databricks together. Fabric may consume Databricks-managed data through OneLake\/shortcuts or shared cloud storage, while Databricks governs the assets, credentials, and workspace access on its side.<\/p>\n The existing Unity Catalog governance<\/a> and Unity Catalog for AI<\/a> articles provide broader governance context. This page focuses on the current Azure Databricks operating model.<\/p>\n Most Unity Catalog data and AI objects are addressed as Catalog is the primary isolation and organization boundary, schemas group related assets, and the object can be a table, view, volume, function, model, or other governed asset.<\/p>\n Design names around stable domains and ownership rather than mirroring every temporary team structure. Renaming or moving assets later affects code, permissions, lineage, and downstream references.<\/p>\n Microsoft currently states that Azure Databricks workspaces created after November 9, 2023 are automatically enabled for Unity Catalog.<\/p>\n Older workspaces may still require upgrade\/migration, and enabling an existing workspace for a metastore is not reversible.<\/p>\n Platform teams should inventory legacy workspaces rather than assume every environment behaves like a newly created workspace.<\/p>\n For managed tables and volumes, Unity Catalog governs both permissions and the underlying data lifecycle.<\/p>\n For external tables\/volumes, Unity Catalog governs the securable object while data remains in an external location whose storage lifecycle is owned separately.<\/p>\n This distinction matters for backup, deletion, migration, and Fabric integration. Dropping an external object is not the same operational act as deleting a managed asset.<\/p>\n Unity Catalog uses storage credentials and external locations to control access to cloud storage for external data.<\/p>\n Users do not need direct access keys embedded in notebooks; permissions can be granted on governed locations and the platform uses the configured cloud identity.<\/p>\n Keep external locations aligned with meaningful data zones and avoid one giant credential\/location that gives every workspace path-level reach across the entire storage account.<\/p>\n Unity Catalog can bind catalogs, external locations, or storage credentials to selected workspaces.<\/p>\n This creates a second governance boundary beyond object privileges. A user might have catalog privileges but be unable to access that catalog from an unbound workspace.<\/p>\n Use workspace binding for environment isolation, regulated workloads, or production-only credentials rather than relying only on naming conventions such as Unity Catalog requires supported compute and correct access modes. Current Azure Databricks requirements support Unity Catalog on Runtime 11.3 LTS or later, with newer features sometimes requiring newer runtimes.<\/p>\n Cluster access mode determines user isolation and which Unity Catalog features are available.<\/p>\n Platform policy should prevent users from creating incompatible or overly permissive compute that undermines the intended data-governance design.<\/p>\n Unity Catalog securables support granular privileges such as USE CATALOG, USE SCHEMA, SELECT, MODIFY, EXECUTE, READ VOLUME, and ownership\/management privileges depending on object type.<\/p>\n Grant to account-level groups where possible so identity lifecycle is handled through directory provisioning instead of one-off table grants.<\/p>\n Use separate data-owner, producer, and consumer roles and keep ownership on a managed group\/service identity rather than an individual employee account.<\/p>\n Unity Catalog automatically captures lineage for supported Databricks workloads and provides audit-log system tables for activity analysis.<\/p>\n Use lineage during change review to understand downstream impact before a table\/schema is modified.<\/p>\n Use audit evidence during incident response to identify who accessed or changed governed data, which workspace\/compute was involved, and whether the behavior crossed an expected domain boundary.<\/p>\n Current Unity Catalog supports row filters, column masks, and attribute-based access-control capabilities in addition to object privileges.<\/p>\n These controls are useful when several audiences share one table but require different views of sensitive columns or rows.<\/p>\n Keep policy functions and governed tags versioned and tested because a change can affect every query against the asset, including downstream BI and AI workflows.<\/p>\n Catalog Explorer, discover experiences, tags, comments, lineage, certification\/deprecation markers, and AI-assisted metadata help users find trusted assets.<\/p>\n Governance fails when users cannot locate the approved dataset and copy it into their own workspace out of frustration.<\/p>\n Use certification, ownership, business descriptions, and deprecation actively so Unity Catalog becomes a discovery product, not only a permissions engine.<\/p>\n When Fabric consumes data governed by Databricks, decide which system owns the canonical storage, who owns cross-platform credentials, and how row\/column\/tenant controls carry across the boundary.<\/p>\n A OneLake shortcut or external storage path can expose files that Unity Catalog normally controls through Databricks semantics. Do not assume governance automatically transfers because both products run in Azure.<\/p>\nThe three-level namespace is the core mental model<\/h3>\n
catalog.schema.object<\/code>.<\/p>\nUnity Catalog is now the default for modern Azure Databricks workspaces<\/h3>\n
Managed and external assets have different storage ownership<\/h3>\n
Storage credentials and external locations separate cloud identity from table permissions<\/h3>\n
Workspace bindings limit where catalogs and credentials are usable<\/h3>\n
prod_<\/code>.<\/p>\nCompute access mode is part of the security boundary<\/h3>\n
Privileges should be granted to groups, not ad hoc users<\/h3>\n
Lineage and audit should be operational tools, not compliance decoration<\/h3>\n
Row, column, and attribute policies can add fine-grained controls<\/h3>\n
Data discovery and certification reduce duplicate datasets<\/h3>\n
Fabric integration should preserve the source governance model<\/h3>\n