REVOKE removes previously granted privileges from Redshift objects, instantly blocking access for specified users, groups, or roles.
REVOKE removes or restricts privileges that were previously granted to users, groups, or roles on objects such as databases, schemas, tables, views, functions, and stored procedures. It is the inverse of GRANT and takes effect immediately.
Run REVOKE with the privilege, object type, object name, and grantee list. Redshift stops the grantee from reading the table right away.
REVOKE SELECT ON TABLE public.orders FROM ROLE analyst_role;
Separate privileges with commas in the same statement for a clean, atomic change.
REVOKE INSERT, UPDATE ON TABLE public.products FROM GROUP data_loaders;
Combine ALTER DEFAULT PRIVILEGES with REVOKE to change permissions for future objects created by a user or role.
ALTER DEFAULT PRIVILEGES FOR USER app_owner IN SCHEMA public
REVOKE SELECT ON TABLES FROM PUBLIC;
Use the ALL shorthand to remove every possible privilege in one command. Be cautious—users lose every permission on the object.
REVOKE ALL ON DATABASE ecommerce_db FROM USER alice;
Audit privileges regularly, use groups or roles instead of single users, script changes in version control, and test in staging before production.
Missing CASCADE: Redshift defaults to RESTRICT, so dependent privileges block the statement. Add CASCADE to forcefully drop them.
Revoking from wrong level: Removing table privileges doesn’t affect default privileges. Check both current and default grants.
Query SVV_TABLE_PRIVILEGES or PG_TABLE_DEF to see who holds which rights.
No. Active sessions keep their permissions until the transaction ends; new queries use the updated privileges.
Yes—simply GRANT the needed privileges back to the user, group, or role.