ABAC requirements, quotas, and limitations
This page lists requirements, policy quotas, and current limitations for attribute-based access control (ABAC) in Unity Catalog.
Compute requirements
To use ABAC policies, you must use one of the following compute configurations:
- Serverless compute
- Standard compute on Databricks Runtime 16.4 or above
- Dedicated compute on Databricks Runtime 16.4 or above with fine-grained access control filtering enabled
For guidance on running workloads that require older runtimes, see Access from older runtimes.
Governed tags requirement
ABAC policies use governed tags, not ungoverned tags. Governed tags are defined at the account level with access controls that determine who can create, assign, and manage them. For full details, see Governed tags.
After assigning or modifying a tag, it can take a few minutes for the change to take effect.
Policy quotas
Resource | Limit |
|---|---|
Policies per metastore | 10,000 |
Policies per catalog or schema | 100 |
Policies per table | 50 |
Principals per policy (applies to both | 20 |
Column conditions per | 3 |
For more details, including governed tags quotas, see Service limits.
ABAC limitations
Access from older runtimes
Standard and dedicated compute on Databricks Runtime versions earlier than 16.4 can't access ABAC-secured tables. If you need certain workloads to continue running on an older runtime, scope the ABAC policy to a specific group instead of applying it broadly. Add only the users or principals you want the policy to apply to that group, and exclude the principal that runs the older-runtime workload using the EXCEPT clause. Users outside the group retain full access to the underlying tables. This allows that workload to continue accessing the tables while you transition to a supported runtime.
ABAC policies on views
You can't apply ABAC policies directly to views. However, when a user queries a view that references tables with ABAC policies, those policies are respected when accessing data through the view.
ABAC row filters and column masks on the underlying tables are evaluated using the session user's identity, meaning the person running the query. The user sees only the rows and column values they are authorized to access, as defined by the ABAC policies on the base tables. Base table access checks and access checks to dependencies use the view owner's identity, so users can query views without direct privileges on the underlying tables.
The same session user identity model applies when tables with ABAC policies are accessed through functions.
The session user identity model was introduced alongside the ABAC GA release. Previously, policies were evaluated using the view owner's or function definer's identity. For more information, see the April 2026 release notes.
ABAC policies on materialized views and streaming tables
Previously, ABAC policies on Materialized views and streaming tables were only supported when the pipeline owner or the run-as identity was exempt from the policy. That limitation has been removed.
When a pipeline refreshes a Materialized view or streaming table, policies are evaluated using the pipeline owner's or run-as identity. If that identity is subject to the policy, the Materialized view or streaming table permanently contains masked or filtered data. Databricks recommends keeping the refresh identity exempt using the EXCEPT clause and targeting consumers who should see masked or filtered data in the TO clause.
Delta Sharing tables with ABAC policies or views that reference them
Tables with ABAC policies or views that reference tables with ABAC policies can only be shared through Delta Sharing if the share owner is exempt from the policy (listed in the EXCEPT clause). The policy doesn't govern the recipient's access. Recipients can apply their own ABAC policies to shared tables to enforce access control on their side.
- For share providers, see Add tables and schemas secured by ABAC policies to a share.
- For share recipients, see Read ABAC-secured data and apply ABAC policies.
For details on how to use Delta Sharing with ABAC, see Delta Sharing and ABAC.
Time travel and cloning on tables with ABAC policies
ABAC policies can't be evaluated against historical table snapshots, so time travel queries fail on tables with active row filters or column masks. Deep and shallow clones also aren't supported on tables with ABAC policies.
To enable these operations, create a service principal or group and add it to the policy's EXCEPT clause. The policy isn't evaluated for exempted principals, so these operations can run.
Exempted principals see unfiltered, unmasked data. Only exempt trusted identities such as service principals used for ETL or pipeline workloads.
For example, the following policy masks PII columns for all users except the etl_service_principal, which can run time travel queries and clone operations:
CREATE POLICY mask_pii
ON CATALOG prod
COLUMN MASK prod.governance.mask_value
TO `account users`
EXCEPT `etl_service_principal`
FOR TABLES
MATCH COLUMNS
has_tag_value('pii', 'ssn') AS ssn
ON COLUMN ssn;
Vector search indexes and ABAC policies
ABAC policies on a source table don't apply to vector search indexes created from that table. The index syncs all rows from the source table and doesn't enforce row filter or column mask policies when serving queries.
For tables with column masks, you can exclude masked columns from the index using the columns to sync setting.
Multiple policies on the same table or column for the same user
Only one distinct row filter can resolve at runtime for a given table and a given user, and only one distinct column mask can resolve for a given column and a given user. You can define multiple policies, but when a user queries the table, only one policy's conditions must match. If multiple distinct row filters or column masks apply to the same user and table or column, Databricks blocks access and returns an error. Multiple policies are allowed if they resolve to the same row filter or column mask UDF with the same arguments.
For details, see Rules for multiple filters and masks.
ABAC policies and information schema
There's no information schema table for ABAC policies. The information_schema.row_filters and information_schema.column_masks tables show only table-level row filters and column masks. They don't show ABAC policy definitions or the filters and masks derived from ABAC policies at runtime.
To list ABAC policies, use the Unity Catalog REST API. Policy creation, modification, and deletion events are captured in the audit log system table.
ABAC on dedicated compute
For limitations of ABAC on dedicated compute, see Limitations.
Limitations common to ABAC and table-level row filters and column masks
For general limitations of row filters and column masks that apply to both ABAC and table-level row filters and column masks, see Limitations.