Notifications
Clear all
Topic starter
07/06/2026 9:04 pm
TL;DR: Listing PostgreSQL users is straightforward with psql, pgAdmin, and catalog queries, but the real security issue is whether teams can actually see roles, privileges, and session activity well enough to audit access and spot misuse, according to StrongDM. The operational gap is governance, not syntax: access visibility only matters when it is tied to review, logging, and revocation decisions.
NHIMG editorial — based on content published by StrongDM: How To List Users in PostgreSQL (psql command & GUI tools)
By the numbers:
- Up to 80% of data breaches in the U.S. start with unauthorized access.
Questions worth separating out
Q: How should teams review PostgreSQL users for access governance?
A: Review PostgreSQL users by combining direct role listing with membership, privilege, and login checks.
Q: Why do PostgreSQL role memberships create hidden access risk?
A: Role memberships can hide effective privilege because a user may inherit permissions from one or more group roles.
Q: What signals show PostgreSQL access is drifting beyond its intended scope?
A: Look for dormant roles that still have login rights, accounts with broad inherited privileges, and users whose membership no longer matches their job or service function.
Practitioner guidance
- Inventory direct and inherited PostgreSQL privileges Run role and membership queries together so you can see both explicit grants and permissions inherited through group roles.
- Turn role listings into recertification evidence Use pg_roles output as the starting point for access review, then validate whether each account still has a business purpose, an owner, and a current approval trail.
- Enable login and role-change logging Capture user logins, logouts, schema changes, and role modifications before depending on manual checks.
What's in the full article
StrongDM's full how-to covers the operational detail this post intentionally leaves for the source:
- Exact psql commands and SQL queries for listing roles, memberships, and privileges across PostgreSQL objects
- GUI walkthroughs for pgAdmin, DBeaver, and DataGrip so database teams can replicate the workflow in their own tools
- Step-by-step examples for creating, granting, revoking, and deleting roles in live PostgreSQL environments
- Troubleshooting guidance for permission-denied errors and missing users in \\du output
👉 Read StrongDM's guide to listing PostgreSQL users and roles →
PostgreSQL roles and access reviews: are your controls keeping up?
Explore further
08/06/2026 8:51 am
Database user listing is a visibility control, not a governance outcome. Listing roles in PostgreSQL only tells you what exists at a point in time. It does not tell you whether the account is still needed, whether the effective privileges are inherited, or whether the access path is being used as intended. Teams that treat enumeration as the control end up with audit comfort and weak entitlement hygiene. The practitioner conclusion is simple: visibility without review is inventory, not governance.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to the same report.
A question worth separating out:
Q: What should teams do when PostgreSQL access reviews uncover outdated roles?
A: Revoke the unnecessary grants first, then remove unused login rights and decommission accounts that no longer have a clear owner. For any role that must remain, document the approval basis and the next review date. Strong database governance depends on closing the loop between listing, audit, and revocation.
👉 Read our full editorial: PostgreSQL user listing exposes the governance gap in database access
