REVOKE removes previously granted privileges or role assignments from users or roles.
Teams revoke privileges to tighten security, off-board teammates, or clean up overly broad grants. Removing unnecessary access reduces accidental data exposure and follows the principle of least privilege.
You can revoke privileges on warehouses, databases, schemas, tables, views, stages, and more. You can also revoke a role that was granted to another role or to a user.
Run REVOKE <privilege> ON <object_type> <object_name> FROM ROLE <role_name>;
. Example below shows removing SELECT
from one table.
REVOKE SELECT ON TABLE Orders FROM ROLE analyst_role;
List privileges comma-separated: REVOKE SELECT, INSERT ON TABLE Orders FROM ROLE analyst_role;
. This shortens maintenance scripts.
Use REVOKE ROLE <child_role> FROM ROLE <parent_role>;
or REVOKE ROLE <role> FROM USER <username>;
to trim nested or direct role assignments.
No automatic cascade. You must revoke on each dependent object or use scripts to iterate through children. Plan revokes carefully to avoid orphaned access.
Always test in lower environments, capture current grants with SHOW GRANTS
, and back them up. Communicate upcoming changes to affected users. Schedule revokes during low-traffic hours.
Only if you add GRANT OPTION FOR
before the privilege list. Otherwise, you remove direct access but the role can still grant the privilege.
You cannot roll back after commit. Re-grant privileges with the same syntax used originally: GRANT SELECT ON TABLE Orders TO ROLE analyst_role;
The executing role needs the OWNERSHIP privilege on the object or the MANAGE GRANTS global privilege.