Notifications
Clear all
Topic starter
08/06/2026 4:57 pm
TL;DR: Listing all PostgreSQL databases is presented as an operational task, but the real issue is whether access to inventory, metadata, and administrative controls is governed tightly enough to avoid unintended exposure, according to StrongDM. For IAM teams, the lesson is that database visibility, privilege scope, and auditability belong in the same governance conversation as access paths.
NHIMG editorial — based on content published by StrongDM: How to List All Databases in PostgreSQL (psql and More)
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
Questions worth separating out
Q: How should security teams govern database listing access in PostgreSQL?
A: Treat database listing as a privileged visibility task, not a default convenience.
Q: Why does PostgreSQL database enumeration matter to least privilege?
A: Because database listing reveals environment structure, and structure is often the first step toward misuse.
Q: What do teams get wrong when they loosen pg_hba.conf for convenience?
A: They often treat it as a connectivity fix instead of an identity control.
Practitioner guidance
- Separate inventory access from administrative access Create a distinct role for listing PostgreSQL databases and keep it read-only.
- Review host-based authentication rules before widening access Check pg_hba.conf, listen_addresses, and authentication methods before loosening controls to solve a connection issue.
- Log and review every database inventory action Capture database enumeration activity alongside other privileged actions so you can see which identities are routinely discovering environments.
What's in the full article
StrongDM's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step psql, pgAdmin, DBeaver, script, and Docker commands for listing databases in PostgreSQL.
- Practical notes on when template databases are excluded from query results and when they are not.
- Troubleshooting details for permission denied errors, authentication methods, and connection checks.
- Tool-specific interface steps for administrators who need to reproduce the workflow exactly.
👉 Read StrongDM's guide to listing PostgreSQL databases across psql, pgAdmin, and more →
PostgreSQL database visibility: what IAM teams should actually enforce?
Explore further
08/06/2026 6:51 pm
Database inventory is an access-control decision, not a convenience feature. PostgreSQL database listing only looks operational on the surface. In governance terms, it exposes who can observe the structure of an environment and who can move from observation to action. That distinction matters because visibility often expands during troubleshooting and never gets tightened again. The practitioner conclusion is simple: treat database enumeration as part of privileged access design, not an afterthought.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
A question worth separating out:
A: The difference is mostly in the interface, not in the access problem. Both depend on the authenticated identity and the permissions granted to that identity. Teams should govern who can enumerate databases, who can administer them, and who can only view them, regardless of whether the person uses psql, pgAdmin, or another client.
👉 Read our full editorial: PostgreSQL database listing is really an access control problem
