Restricting what a user group can see with column masking and row-level security

Unity Catalog supports fine-grained access control through column masks and row filters, which use SQL functions to dynamically restrict what data users see based on their identity or group membership. These are applied at the table level via ALTER TABLE and enforced automatically for every query against that table, regardless of the tool used to access it.

1 · Learn the must-know

• 1Row filters are SQL functions that return a BOOLEAN, applied to a table with ALTER TABLE ... SET ROW FILTER, and Databricks evaluates the function per row, hiding rows where it returns false.
• 2Column masks are SQL functions applied with ALTER TABLE ... ALTER COLUMN ... SET MASK, and they transform or redact the column value (e.g., show NULL or a hashed value) rather than hiding the row.
• 3Both mechanisms commonly use is_account_group_member() or similar group-membership checks inside the masking/filtering function to conditionally reveal or obscure data.
• 4Masks and filters are enforced consistently across all access paths (SQL warehouses, notebooks, JDBC/ODBC, Delta Sharing where applicable) since enforcement happens at the table/query layer in Unity Catalog, not in a specific client.
• 5A single column can only have one mask, and a single table can only have one row filter at a time, though the underlying function can encode multiple conditions.
• 6Users must have appropriate privileges to create or alter these functions and apply them; regular table consumers are unaware the masking/filtering exists and simply see restricted results.

2 · Check your understanding