Redshift user management covers creating, altering, dropping, and granting privileges to database users.
Managing users means creating logins, setting passwords, assigning default schemas, adjusting quotas, revoking access, and deleting accounts when no longer needed. The goal is least-privilege access and easy auditing.
Run CREATE USER
with a strong password and optional defaults.Always assign a group or role immediately to enforce privilege boundaries.
CREATE USER analyst_pw WITH PASSWORD 'S3cure#2024'
VALID UNTIL '2025-12-31'
IN GROUP analysts;
Use ALTER USER
to rotate passwords, lock accounts, or move users between groups without impacting their objects.
ALTER USER analyst_pw PASSWORD 'N3wS3cure#2025';
First transfer or delete owned objects, then execute DROP USER
.Add IF EXISTS
to avoid errors in automation scripts.
REASSIGN OWNED BY analyst_pw TO admin;
DROP USER IF EXISTS analyst_pw;
Prefer group or role grants.Use GRANT SELECT ON
for read-only analytics, and GRANT USAGE ON SCHEMA
so users can access objects inside schemas.
GRANT USAGE ON SCHEMA sales TO analysts;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO analysts;
Automate password rotation, map users to IAM roles, disable unused accounts, and log all DDL in STL tables for auditing.Keep groups task-oriented, not person-oriented.
Query PG_USER
, PG_GROUP
, and SVL_QLOG
to list accounts, group memberships, and recent activity. Export results for security reviews.
.
Yes. Run ALTER USER username PASSWORD DISABLE;
. The account remains but cannot log in until a new password is set.
Set VALID UNTIL
when creating or altering a user. Your IAM or CI pipeline can alert and reset before expiration.
Groups are simpler in Redshift. If you use Redshift-compatible roles, stick to them consistently; but never mix direct object grants and group grants for the same privilege set.