PostgreSQL
Managed PostgreSQL clusters run by the CloudNativePG operator — instances, storage, compute plans, connections, backups and the Data Explorer.
A PostgreSQL cluster is a managed PostgreSQL database in a resource group. The platform runs it with the CloudNativePG operator on the Kubernetes cluster you place it on: you choose a version, a compute plan and a few options, and the operator creates the database, keeps its instances running, replaces an instance that fails and, when backups are on, archives it continuously. In the portal the clusters are under PostgreSQL in the sidebar.
Instances
A cluster runs 1 to 10 instances. Each instance is a pod with its own copy of the data on its own volumes. One instance is the primary, which takes the writes; the others are replicas that follow it. With more than one instance the operator promotes a replica when the primary fails — see Instances and high availability.
The database and its user
A cluster holds one database, named when you create it. It is owned by a user with the same name, and that user is the one the cluster's connection string logs in as. The platform hands out no other credentials for the cluster.
Compute plans and storage
A compute plan sets the CPU and memory of each instance, the number of instances and the
initial size of the volumes, and tunes PostgreSQL's memory settings and connection ceiling to that
size. Each instance has a data volume and, on every plan but nano, a separate volume for the
write-ahead log (WAL). Volumes can grow but never shrink, and their storage class is fixed when the
cluster is created. The plans are listed in Compute plans and parameters.
Connections
Workloads connect with the cluster's connection string, which the platform shows only to those allowed to read it; every reveal is recorded in the cluster's activity. PostgreSQL refuses every connection that does not use TLS. The Firewall setting narrows which workloads may connect, the cluster can be exposed outside the Kubernetes cluster on a load balancer, and with PgBouncer on a connection pooler runs in front of the primary. See Connect to a cluster and Network access.
Backups
With backups on, the cluster streams its write-ahead log to the platform's backup store and takes base backups — snapshots — on a schedule and whenever you ask. A snapshot, or any point in time the archive covers, can be restored in place. See Backups and point-in-time recovery.
Data Explorer
The cluster's Data Explorer tab browses schemas and tables, edits rows and runs SQL. Every statement is checked against your permissions before it runs, and some are never allowed. Using it needs the Database Explorer role, which no other built-in role includes — see Use the Data Explorer.
Pages
- Create a cluster
- Connect to a cluster
- Network access
- Manage a cluster — start, stop, plans, instances, storage, pooling, parameters, deleting
- Compute plans and parameters
- Instances and high availability
- Backups and point-in-time recovery
- Use the Data Explorer
- Create schemas and tables
- Find out why a cluster is not ready
- Permissions
- Names, limits and statuses