Unity Catalog is Databricks' governance layer for data and AI assets. It organizes tables, views, volumes and models in a three-level namespace of catalog, schema and object, and controls who can read and write each one.
For example, a table might be named prod.sales.orders: the catalog prod, the schema sales and the table orders. A data engineering team can hold MODIFY on the schema, analysts SELECT on a few of its tables, and a nightly job can run as a service principal with exactly the grants its tables need. USE CATALOG and USE SCHEMA must also be granted before anyone can reach a table, which is a frequent cause of errors that look like a missing table but are really missing permissions.
Beyond permissions, Unity Catalog records lineage for queries run on Databricks, audit logs of who accessed what, tags and comments for discovery, and volumes for files that are not tables. External locations and storage credentials control which cloud storage paths a workspace can read and write. Many teams use separate catalogs per environment, such as dev and prod, so the same code can run in both by changing one name.
Because permissions live in the catalog rather than in code, a pipeline can be correct and still fail in production for lack of a grant, or succeed in development only because a developer has broad rights that a job does not. Testing jobs with the identity they run as avoids both surprises. See also Delta Lake, lakehouse and Databricks Asset Bundle.
For local tests, Unity Catalog metadata such as column names, types and comments is what lets a tool sample the right tables without asking you to describe them. See also orchestration.
Permissions in Unity Catalog decide what users and jobs can access, which makes them a common source of deploy failures: a job can pass its tests on your machine and still lack a grant. Emolysis's Databricks profile lists them as a known trap, and its catalog mirror reads Unity Catalog metadata. See Connecting Databricks.