Notifications
Clear all
Topic starter
08/06/2026 4:58 pm
TL;DR: PostgreSQL query auditing can capture who did what and when through native logs, pgAudit, or a proxy layer, but each option shifts cost, detail, and operational burden, according to StrongDM. The governance problem is not just logging more, but preserving usable audit evidence without creating new performance or offboarding gaps.
NHIMG editorial — based on content published by StrongDM: PostgreSQL Log Queries and Audit
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
Questions worth separating out
Q: How should security teams log PostgreSQL activity without hurting performance?
A: Use a tiered approach.
Q: Why do PostgreSQL audit logs matter for identity governance?
A: Because they connect a person or vendor account to a real action inside a production database.
Q: What breaks when PostgreSQL logging is left local only?
A: Local-only logging breaks central visibility.
Practitioner guidance
- Map audit depth to data sensitivity Apply the highest-fidelity logging only to databases that handle PII, PHI, or regulated workloads.
- Centralise PostgreSQL logs immediately Send logs to a shared collector or SIEM as part of the baseline design, especially where more than one node exists.
- Tie database logs to joiner-mover-leaver events Review which human and third-party identities still have active database access after role changes, contract changes, or offboarding.
What's in the full article
StrongDM's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step PostgreSQL log configuration for statement capture and CSV output
- PgAudit examples that show how individual SQL actions appear in the audit trail
- Proxy-based logging tradeoffs for teams that need visibility without extra database I/O
- StrongDM audit command examples for permissions, queries, SSH, RDP, and kubectl access
👉 Read StrongDM's PostgreSQL query logging and audit guide →
PostgreSQL query auditing: what IAM and security teams need to know?
Explore further
08/06/2026 6:52 pm
Audit logging is an access accountability control, not a database convenience feature. The article makes clear that query logging exists because teams need to reconstruct who touched sensitive data and when. That places PostgreSQL logging inside the broader IAM and governance problem of proving authorised activity, especially where human, consultant, and vendor access all intersect. Practitioners should treat it as evidence infrastructure, not an optional operations tool.
A few things that frame the scale:
- 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.
- Only 5.7% of organisations have full visibility into their service accounts, which is why audit trails must be designed for discoverability as well as retention.
A question worth separating out:
Q: Should organisations use proxy logging or native PostgreSQL audit features?
A: Choose based on the control objective. Native logging and PgAudit provide deeper database detail, while proxy logging reduces runtime load and is easier to keep always on. If the priority is forensic precision, stay closer to the database. If the priority is stable production performance, move the logging burden outward.
👉 Read our full editorial: PostgreSQL query auditing exposes the access logging tradeoff
