# One grant model for tables, files and models in Unity Catalog > Security reviews stall when nobody can say who reads which table, file or model. How Unity Catalog put all three under one set of grants at Location Services. Published: 2026-10-26 Author: Preetham Reddy Tags: Databricks Canonical: https://www.techfabric.com/blog/one-grant-model-for-tables-files-and-models-in-unity-catalog --- We moved [Location Services](/case-studies/vrm) off Synapse and SQL Server onto Databricks in waves that could each be rolled back, with [TechFabric Airlift](/accelerators/airlift) running each wave and no wave cutting over until its signed migration certificate was issued. The rules engine that checks every assignment, from VIN decode to bankruptcy and lot checks, came through unchanged. Lakebase now carries the operational data it reads and writes, and Unity Gateway sits in front of its model calls. Unity Catalog ended up holding the grants for all of it. Who can reach the tables, the files and the model calls became one place to look, where before there was one per system. People describe Unity Catalog as a catalogue for tables, and it is one. For a company deciding whether Databricks will pass its own security review, the bigger change is that files and models sit under the same names and the same grants as the tables. ## Before Unity Catalog, every workspace kept its own rules Each workspace had its own Hive metastore and its own table access controls. Files sat behind DBFS mounts, and anyone with access to the workspace could read through a mount. Models lived in a workspace registry with permissions of its own. A company with five workspaces had five answers to "who can read the customer table?", plus whatever the mounts and the registry allowed on the side. The fix people reach for first is a second catalogue, a governance tool or context store that sits next to Databricks and records access centrally. We considered that path and didn't take it, because two systems end up disagreeing about who can read the customer table, and the answer a reviewer gets depends on which one they ask. We keep Unity Catalog as the single place access is decided, the same argument I made in [Unity Catalog for enterprise data governance](/blog/beyond-basic-data-catalogs-how-unity-catalog-solves-real-enterprise-governance-challenges). ## Three names for every table, volume and model Unity Catalog gives every governed object a three-part name, `catalog.schema.object`. A table is `finance.claims.payments`. A folder of PDFs is a volume, `finance.claims.documents`, which you read at `/Volumes/finance/claims/documents/`. A model registered from MLflow is `finance.claims.fraud_scorer`. Functions follow the same pattern. Because notebooks, jobs, dashboards and agents all reach data by that name, a grant on it means the same thing in each of them. Volumes and external locations take over the job mount points used to do, so a folder of claim PDFs gets a grant like any table. ```mermaid %% caption: One grant on a schema reaches the table, the volume and the model inside it, and lineage follows the table to the dashboard. flowchart TD M["Metastore"] --> C["Catalog: finance"] C --> S["Schema: finance.claims"] S --> T["Table: payments"] S --> V["Volume: documents"] S --> R["Model: fraud_scorer"] G["GRANT to claims-analysts on the schema"] --> S SRC["Source table"] --> T T --> D["Dashboard"] class G accent ``` ## Grants written once in SQL Access is plain SQL, `GRANT` and `REVOKE`, and [a privilege granted on a catalog or schema is inherited](https://docs.databricks.com/aws/en/data-governance/unity-catalog/manage-privileges/privileges) by everything inside it, now and later. We grant to groups, so joining a team is what changes someone's access, and as high in the hierarchy as the access really goes. ```sql GRANT USE CATALOG ON CATALOG finance TO `claims-analysts`; GRANT USE SCHEMA ON SCHEMA finance.claims TO `claims-analysts`; GRANT SELECT, READ VOLUME, EXECUTE ON SCHEMA finance.claims TO `claims-analysts`; ``` Those three lines let the group read the table, read the files in the volume and load the model for inference. Taking it away is the same statement turned around, ``REVOKE SELECT ON SCHEMA finance.claims FROM `claims-analysts` ``. When one table needs tighter access than the rest of its schema, it's simpler to move it to its own schema or put a row filter or column mask on it than to carve exceptions out of a schema-wide grant. The grants live in the metastore, and every workspace attached to that metastore enforces them. Databricks requires [one metastore for each region](https://docs.databricks.com/aws/en/data-governance/unity-catalog/create-metastore) an organization operates in, so a company that runs Databricks in two regions still has two places to keep in step. A catalog can also be [bound to specific workspaces](https://docs.databricks.com/aws/en/catalogs/binding), so only those workspaces can access it. We run agents and applications under their own service principals, so an agent reaches only what its principal was granted. A grant only covers reads through Databricks, though. When we tested DuckDB against our own Azure metastore on 21 October, 21 of our 32 managed tables sat on Databricks default storage, and Unity Catalog wouldn't vend a storage credential for any of them to an engine outside Databricks, whatever the user's grants said. That test has [its own post](/blog/duckdb-view-only-catalog-over-delta-lake), and it's why we check where the files live before promising anyone outside access. ## Lineage that records itself Unity Catalog [captures lineage automatically](https://docs.databricks.com/aws/en/data-governance/unity-catalog/data-lineage) for queries run on Databricks, down to the column, with no code from anyone. A notebook, a job, the SQL editor or a dashboard that reads one table and writes another leaves a record in system tables that keep a rolling year of history. ```sql SELECT source_table_full_name, target_table_full_name, entity_type, created_by, event_time FROM system.access.table_lineage WHERE target_table_full_name = 'finance.claims.payments' ORDER BY event_time DESC; ``` With access in `system.access.audit` and lineage in `system.access.table_lineage`, "who can see this?" became a query instead of an investigation. The lineage has gaps. A user-defined function gets table-level lineage only, and jobs started with `runs submit` don't appear in the lineage views. Work outside Databricks, such as a Salesforce source or a Power BI report, shows up only once someone registers it as external lineage metadata, so it's worth listing those systems before an audit asks about them. ## What the job-posting data says about demand Kyle Cheung [published Crustdata's job-posting data](https://www.linkedin.com/posts/cheung-kyle_last-week-someone-asked-us-which-is-growing-share-7512893227515961344-HhMk/) on how often each platform appears in data engineer postings. Databricks went from about 12% of them in early 2024 to 23.9% in mid 2026, roughly doubling, and it leads Snowflake, at 21.8%, in the latest quarter. A company moving to Databricks for governance needs engineers who can design the catalog, the schemas and the group grants in Unity Catalog before the pipelines land, and that design is where our governance engagements start. ## Where to start with an estate you already have If you already run Databricks, list what's still in `hive_metastore` and which mounts are still in use before you design anything, because that inventory usually shrinks the job. The two-week [Databricks Health Check](/databricks/health-check) does that and reads the grants and lineage as they stand. If you're standing a lakehouse up from scratch, the [Lakehouse Launchpad](/databricks/launchpad) puts Unity Catalog in place before the first pipeline lands. ## Frequently asked questions ### What is the three-level namespace in Unity Catalog? Every governed object has a name of the form `catalog.schema.object`. The object can be a table, a view, a volume of files, a registered model or a function. Because every tool reaches data by the same name, a grant on that name means the same thing in a notebook, a job, a dashboard or an agent. ### Can Unity Catalog govern files and AI models as well as tables? Yes. Files go in volumes, which take the privileges `READ VOLUME` and `WRITE VOLUME`, and models registered from MLflow take `EXECUTE`, which lets a user load the model for inference. Both sit inside a schema next to its tables, so a grant on the schema can cover all three. ### Do Unity Catalog grants apply across all workspaces? Across every workspace attached to the same metastore. Databricks requires [one metastore for each region](https://docs.databricks.com/aws/en/data-governance/unity-catalog/create-metastore), so a company in two regions has two metastores to keep in step. A catalog can also be [bound to specific workspaces](https://docs.databricks.com/aws/en/catalogs/binding), so only those workspaces can access it. ### Is Unity Catalog lineage captured automatically? For work that runs on Databricks, yes. Queries from notebooks, jobs, the SQL editor and dashboards are recorded down to the column, and you can query them in `system.access.table_lineage` and `system.access.column_lineage`. Work outside Databricks appears only once it's registered as external lineage metadata. ### Is demand for Databricks data engineers growing? Yes. Crustdata's job-posting data, published by Kyle Cheung, shows Databricks in about 12% of data engineer postings in early 2024 and 23.9% in mid 2026, ahead of Snowflake at 21.8% in the latest quarter.