Join our Newsletter — 33% off our NHI Course

pg_database

pg_database is the PostgreSQL system catalogue that stores one row for each database in a cluster. It records the database name, owner, encoding and access flags, and is queried by administrative tools and internal catalogue functions when managing databases and permissions.

What pg_database Represents

pg_database is the PostgreSQL catalog table that serves as the cluster’s registry of databases. Each row describes one database and captures the metadata PostgreSQL needs to manage it, including ownership, encoding, and access flags.

Because it is a system catalogue rather than an application table, pg_database sits inside PostgreSQL’s internal metadata layer. Administrative tools and backend catalogue functions consult it to understand which databases exist and how they are configured for access and management.

Why pg_database Matters Operationally

In practice, pg_database is part of the control plane for a PostgreSQL cluster. If this catalogue is inaccurate, unavailable, or unexpectedly changed, administrators may see failures in database creation, connection routing, permission checks, or cluster-level maintenance tasks.

The table also matters because it is one of the places where PostgreSQL records access-related state. That makes it relevant to routine administration, but also to audits of database ownership and access constraints when operators need to confirm how the cluster is configured.

How PostgreSQL Uses the Catalogue

PostgreSQL uses system catalogues to keep metadata close to the engine that enforces it. pg_database supports internal decisions about which databases exist in the cluster, who owns them, and whether a database should accept connections.

This design reduces ambiguity because the server does not rely on external configuration alone. Instead, administrative behaviour and permission-aware operations can consult the catalogue directly, which is why system metadata is so central to consistent cluster management.

For readers who want the broader hardening context around database catalogues and platform defaults, the CIS Benchmarks are a useful companion reference for baseline configuration discipline.

Administrative and Security Implications

Because pg_database reflects cluster-level metadata, it is useful for troubleshooting and governance, but it is also sensitive. Changes here can affect whether a database is reachable, how it is owned, and how the server interprets access conditions.

For administrators, the key lesson is that catalogue state should be treated as part of the trusted configuration surface. Monitoring and review should focus on unexpected ownership changes, access-flag shifts, and inconsistencies between the intended database estate and what the catalogue actually records.

The NIST National Vulnerability Database can help teams track PostgreSQL-related advisories and version-linked issues that may affect catalogue integrity or database management behaviour.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
CIS Controls v8 CIS-5 — Account Management pg_database tracks database ownership and access state within the cluster.
Recommendation — Review database ownership and access-flag records to detect unauthorized configuration drift.
NIST SP 800-53 Rev 5 CM-8 — System Component Inventory pg_database is the cluster inventory of databases and their metadata.
CM-6 — Configuration Settings pg_database reflects configuration values that affect cluster behaviour and access.
Recommendation — Maintain an authoritative inventory of PostgreSQL databases and reconcile it against pg_database. Lock down and review PostgreSQL catalogue-related configuration changes that alter database access.