CREATE DATABASE privilege is the permission that allows a role to create new databases on a PostgreSQL server. It is a powerful administrative right because it affects server-wide resource use and structure. Teams should assign it sparingly and review it carefully, especially in shared environments with multiple operators or automation paths.
What the privilege actually changes
CREATE DATABASE is a server-level permission in PostgreSQL, not a cosmetic label. It lets a role add new databases to the instance, which means the holder can influence how storage, ownership, and administrative boundaries are expanded across the server.
Because the privilege affects structure rather than a single schema object, it belongs in the same control discussion as other high-impact administrative rights. In practice, the question is not just whether someone can create a database, but whether they should be trusted to expand the server’s footprint without additional review.
Why it matters in shared PostgreSQL environments
In a shared platform, this privilege can become a quiet multiplier of operational and security risk. A role that can create databases can consume resources, introduce unmanaged objects, and create new places where data, extensions, and configuration drift may accumulate.
The risk is strongest when the permission is granted broadly to developers, automation, or support roles that do not need instance-wide authority. It is also more sensitive when database creation is coupled with other administrative capabilities, because the combined effect can weaken segmentation and oversight.
How it should be governed
CREATE DATABASE should be treated as an exceptional entitlement with a clear owner, purpose, and review cadence. The practical standard is to grant it only when there is a documented need to provision new databases as part of the role’s actual job, then remove or scope it when that need ends.
Teams should also distinguish between local convenience and durable authority. Temporary project work, onboarding, migrations, and test environments often need database creation at some point, but that does not justify leaving the privilege in place indefinitely.
For a broader control lens, this fits the least-privilege posture described in the Ultimate Guide to NHIs, especially where automation or operator accounts are part of the provisioning path.
Examples of safe and unsafe use
A safe use case is a small platform team that owns PostgreSQL instance provisioning and needs CREATE DATABASE to deliver approved environments. Even then, the privilege should be tied to named operators, not handed to every account that touches the cluster.
An unsafe use case is a broadly shared role, service account, or CI process that can create databases without change control. In that pattern, the privilege can be used for accidental sprawl, unauthorized experimentation, or destructive post-compromise activity, which is why it deserves the same scrutiny as other powerful administrative rights.
The practical boundary is simple: if the role can create new databases, it can change the server’s shape. That makes review, ownership, and revocation more important than the permission name itself.
Risk and Threat Considerations
CREATE DATABASE can create security exposure when it is granted too widely, especially in shared or automation-heavy PostgreSQL environments. The main concern is uncontrolled expansion of the server’s attack surface, resource footprint, and administrative complexity.
Failure mechanism: A privileged role or automation path creates databases without tight approval, then uses them to bypass intended controls, accumulate unmanaged data, or amplify the impact of later compromise or misuse.
Impact: The server can become harder to govern, easier to abuse, and more difficult to audit, while the organisation inherits extra places for misconfiguration, sprawl, and unauthorized change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | CREATE DATABASE is a privileged entitlement that should be granted and reviewed by business need. |
| Recommendation — Restrict database creation rights to approved roles and review them on a recurring basis. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | The privilege is an access decision that must be governed as part of authorization and privilege management. |
| Recommendation — Apply access-control governance to limit who can create databases and to verify continued need. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Least Privilege and Access Scope | Database-creation rights on shared or automated accounts are a privilege-scope issue central to NHI governance. |
| NHI-03 — Secrets and Credential Management | Database creation is often exercised through privileged automation paths that depend on managed credentials. | |
| Recommendation — Minimise database-creation entitlements and scope them to the smallest viable set of trusted roles. Protect the credentials used for database provisioning and rotate them when access paths change. | ||
| NIST SP 800-63 | IAL/AAL — Digital Identity Assurance and Authenticator Assurance | Administrative database rights rely on trusted identity and authenticated privileged access decisions. |
| Recommendation — Use strong authentication and assurance for accounts that can create databases. | ||
Practitioner Guidance
Governance implication: Treat CREATE DATABASE as a privileged entitlement with explicit ownership and periodic recertification. If the permission is not required for current duties, remove it rather than allowing it to remain by default.
What to watch for: Pay special attention when the privilege appears on shared admin roles, CI/CD accounts, or automation paths. Those are the contexts where a seemingly routine permission can become a platform-wide control issue.
Practitioner takeaway: If a role can create databases, it should be reviewed with the same seriousness as other server-level privileges, because the permission changes both governance scope and operational blast radius.
