Why does granting individual PostgreSQL accounts to every developer become hard to manage at scale?

Why this breaks down as the database estate grows

Individual PostgreSQL accounts create a one-to-one administrative model that works when the team is small, but scales poorly once people, environments, and databases multiply. Every new developer adds another identity to provision, permission, review, and eventually revoke. The management problem is not PostgreSQL itself, it is the amount of per-person state that must stay accurate over time.

That state becomes harder to keep consistent when teams need access to multiple clusters, schemas, and roles. The more exceptions you carry, the more likely permissions drift away from current project need. A small mismatch, such as the wrong role inherited on one database, can persist unnoticed because there are simply too many discrete assignments to inspect manually.

The operational burden also compounds during change. Joiners, movers, and leavers each require updates across roles, grants, and sometimes connected tooling. If access is tied to personal accounts instead of role-driven patterns, every organisational change creates another maintenance event. Over time, the database team spends more effort maintaining access records than managing the access model itself.

What gets harder than just creating the account

Account creation is the easy part. The harder work is making sure the privilege attached to each account remains correct, minimal, and auditable. That includes deciding who needs read versus write access, who can administer objects, and how temporary access expires without leaving behind dormant privileges. As the number of accounts rises, those decisions become slower and more error-prone.

Reviews are where scale pain becomes most visible. Access recertification has to confirm not only that a developer still needs access, but also that the scope of that access still matches the current task. When every person has a separate account, the review process must compare many similar permission sets, which makes over-entitled accounts easier to miss and legitimate exceptions harder to justify.

Temporary, role-driven access reduces this burden because the unit of management becomes the role or group, not each individual login. That does not remove accountability, but it changes the control point. The team can update a small number of role definitions and expiries instead of chasing a growing set of bespoke per-user grants.

Practitioner Guidance

What to verify: If your PostgreSQL access model depends on direct grants to named users, check whether the same permission pattern is being duplicated across many accounts. If so, the scaling problem is already present, even if it has not yet caused an outage or audit issue.

Decision rule: Use individual accounts only when the access pattern is genuinely unique and short lived. If multiple developers regularly need the same database capabilities, move that access into a role or other managed group so the privilege decision is owned once and reused safely.

What to measure: Track how many distinct grants must change when a developer joins, changes project, or leaves. A rising count is a strong signal that the model is accumulating administrative debt and that review cycles will keep slowing down.

Practitioner takeaway: The core scaling failure is not user count by itself, it is the explosion of per-person privilege state. Once the access model depends on many individually maintained grants, routine administration starts to consume the same attention that should be reserved for control quality.

Related resources from NHI Mgmt Group

• When do service accounts become a higher risk than ordinary user accounts?
• Why do connector projects become hard to scale when every integration is built differently?
• Why do traditional permission models become hard to manage as applications and users scale?
• How should security teams govern non-human identities at scale?