Postgres Roles vs Users

Confusion clarified.

Overview

In modern Postgres, “user” and “role” are the same thing: CREATE USER is just an alias for CREATE ROLE WITH LOGIN. The role model is the access-control system, and it supports RBAC through role membership: group roles hold permissions, login roles get added to groups, members inherit. Understanding the model rather than the legacy syntax produces cleaner access control and easier onboarding/offboarding.

• Confusion clarified. CREATE USER is alias for CREATE ROLE WITH LOGIN; modern Postgres has one concept, not two.
• Roles can own roles. Group roles grant permissions to member roles; the model supports RBAC at the database level.
• LOGIN attribute. Distinguishes login-able roles (users) from group roles (permissions containers); semantically clean.
• Inheritance plus SET ROLE. Member roles inherit group permissions; SET ROLE switches to a different role within a session for privilege escalation patterns.

The approach

The practical approach is group roles for RBAC (readers, writers, admins as group roles holding permissions), login roles for users (per-human and per-application logins as members of the appropriate groups), membership for access management (adding a user to a group, not granting per-table permissions to each user), SET ROLE for temporary elevation in ops contexts, and per-database role hierarchy documented in the schema repo so the access model is reviewable.

• Group roles for RBAC. readers, writers, admins as group roles holding permissions; the permission model lives in the groups.
• Login roles for users. Per-human or per-application login; the login role gets added to groups for permissions.
• Membership for access. Add user to group role; permissions follow the group, not the user.
• SET ROLE for elevation plus documented hierarchy. Temporary elevation for ops; per-database role tree committed for operational review.

Why this compounds

Postgres role discipline compounds across the database lifetime. Each correctly-modeled role hierarchy supports clean onboarding and offboarding; each group role survives team turnover; the access model stays auditable rather than degrading into per-table grants accumulated over years.

• Access control. Group roles support RBAC; permissions live in groups rather than scattered across users.
• Lifecycle management. Group membership simplifies onboarding and offboarding; one membership change replaces many per-table grants.
• Audit trail. Per-role access logged; the audit shows who held which group at any point in time.
• Institutional knowledge. Each role decision teaches Postgres patterns; the team builds vocabulary for database access control.

Postgres role discipline is a database discipline that pays off across years. Nova AI Ops integrates with database telemetry, surfaces role patterns, and supports the team’s database security discipline.