How should teams govern access across PostgreSQL and MySQL estates?

Why This Matters for Security Teams

PostgreSQL and MySQL often end up governed as “just databases,” but access risk sits in the identities that reach them, the roles those identities inherit, and the speed at which access is revoked. A single access model is useful because it forces consistent authentication, approval, logging, and offboarding across both estates, even when the underlying permission syntax differs. That matters when service accounts, automation, and analysts all touch sensitive data.

NHI Management Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and 97% carry excessive privileges, which is exactly why database access cannot rely on ad hoc local grants. Current guidance from OWASP Non-Human Identity Top 10 and the Ultimate Guide to NHIs points toward centralized governance, short-lived access, and reviewable accountability rather than server-by-server exceptions. In practice, many security teams encounter privilege sprawl only after a stale account or shared credential has already been used to move laterally across both engines.

How It Works in Practice

The practical model is to separate identity governance from database-specific permissioning. A central control plane decides who or what can connect, while PostgreSQL and MySQL enforce their own native privileges after authentication. That means teams standardise the policy layer, not the SQL grammar. The policy should define approved identities, required MFA or workload authentication, session recording requirements, and the conditions for elevation.

For non-human workloads, the better pattern is workload identity plus just-in-time access. Instead of long-lived database passwords stored in code or shared across tools, an agent, application, or job presents cryptographic proof of identity, receives a short-lived secret or token, and is granted only the role needed for that task. This is consistent with the direction of the Lifecycle Processes for Managing NHIs and the 52 NHI Breaches Analysis, which both emphasise rotation, revocation, and auditability.

• Use a common approval workflow for PostgreSQL and MySQL entitlements, even if the grant statements differ.
• Map business roles to database roles through policy, then avoid direct human-made grants except for break-glass use.
• Issue short-lived credentials through PAM or a secrets broker, with automatic expiry tied to the session or job.
• Record connection metadata, query activity where feasible, and the identity that authorised the session.
• Revoke access centrally when a user, service, or agent changes purpose, ownership, or risk posture.

NIST Cybersecurity Framework 2.0 supports this approach through governed identity and access processes, while the NHI Management Group guidance on offboarding makes clear that revocation discipline is often the weak point. These controls tend to break down when teams allow direct DBA exceptions for each platform, because local grants drift faster than the central review process can detect.

Common Variations and Edge Cases

Tighter database governance often increases operational overhead, so organisations have to balance consistency against application uptime and schema ownership. That tradeoff is real when legacy applications embed static credentials, when BI tools require broad read access, or when replica and maintenance accounts cannot be treated like normal user access.

Current guidance suggests treating these as documented exceptions, not a separate governance model. For example, read-only analytics access can still flow through the same approval and logging path, but may use a distinct role with scoped datasets and shorter review cycles. Likewise, PostgreSQL and MySQL do not need identical permission structures, but they do need consistent control objectives: authenticated entry, least privilege, session visibility, and revocation on change. The Ultimate Guide to NHIs — Key Challenges and Risks is a useful reminder that excessive privilege and poor visibility are usually the real failure modes, not the database brand itself.

Where practice is still evolving is in fully automating database authorisation for autonomous agents. Best practice is moving toward intent-aware, time-bound access, but there is no universal standard for that yet. Teams should therefore anchor on the NIST Cybersecurity Framework 2.0 for governance, while applying the Top 10 NHI Issues to control secret sprawl and over-privileged database accounts.

Related resources from NHI Mgmt Group

• How should security teams govern MySQL user access across many instances?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern access to MCP registry-discovered servers?