Notifications
Clear all
Topic starter
07/06/2026 9:05 pm
TL;DR: Listing PostgreSQL tables is straightforward through psql, SQL, pgAdmin, or scripts, but StrongDM’s guide shows that the real risk is not the query method itself, it is unmanaged credentials, excessive privileges, and blind spots around who can see database metadata. The control problem is proving access, logging it, and revoking it fast enough for real operational use.
NHIMG editorial — based on content published by StrongDM: How to Show/List Tables in PostgreSQL (psql, SQL & pgAdmin)
Questions worth separating out
Q: How should security teams govern PostgreSQL table discovery in production environments?
A: Security teams should treat PostgreSQL table discovery as a governed access event, not a harmless admin task.
Q: Why do stored database credentials increase risk even for read-only table queries?
A: Stored credentials increase risk because they create durable, reusable access that can be copied into shells, scripts, and pipelines.
Q: What breaks when CI/CD pipelines can list tables with long-lived credentials?
A: When CI/CD pipelines can list tables with long-lived credentials, table discovery stops being a bounded task and becomes recurring standing access.
Practitioner guidance
- Separate metadata access from data access Review which roles can query information_schema and pg_catalog, then narrow visibility to the specific schemas needed for support, debugging, or automation.
- Eliminate durable database secrets from scripts and pipelines Replace stored passwords, .pgpass files, and embedded credentials with identity-based access and short-lived authorisation so that table discovery jobs do not inherit reusable secrets.
- Log every table listing path centrally Capture psql sessions, GUI activity, and programmatic queries in a single audit trail so schema discovery is attributable and searchable across teams.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples for listing PostgreSQL tables with psql, SQL, pgAdmin, and Python.
- Troubleshooting guidance for permission errors, schema visibility issues, and client setup problems.
- Practical examples of automating table discovery in CI/CD workflows.
- StrongDM's access-control workflow for enforcing least privilege, logging, and revocation across database sessions.
👉 Read StrongDM's guide to listing PostgreSQL tables securely →
PostgreSQL table discovery: are your database controls keeping up?
Explore further
08/06/2026 8:52 am
Database table discovery is an identity governance problem before it is a database task. The guide frames listing tables as routine administration, but the control question is who can obtain schema visibility and under what authority. In practice, table discovery often reveals privilege sprawl, unmanaged service credentials, and access paths that were granted for convenience and never revisited. The implication is that database metadata access should be governed as a first-class entitlement surface, not treated as harmless read-only activity.
A few things that frame the scale:
- 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Should teams use separate controls for database metadata access and data access?
A: Yes. Metadata access deserves separate controls because schema visibility can reveal enough about database structure to support reconnaissance even without row-level access. Teams should review who can query catalogs, who can connect interactively, and which automation jobs need discovery rights. That separation makes least privilege measurable instead of symbolic.
👉 Read our full editorial: PostgreSQL table listing exposes the IAM gap in database access
