Skip to main content
PGO is tested and supported on all major Kubernetes distributions. Because PGO uses standard Kubernetes APIs and follows the operator pattern, it runs on any distribution that achieves CNCF Kubernetes conformance. Platform-specific notes below describe configuration differences that may apply to your environment.

​
Supported distributions

​
Kubernetes version requirements

PGO targets recent stable Kubernetes releases. The operator uses standard apps/v1, core/v1, batch/v1, and policy/v1 APIs that have been stable since Kubernetes 1.21.
PGO’s CI pipeline tests against a range of minor Kubernetes versions. Consult the release notes for your specific PGO version to see the tested Kubernetes range. In general, PGO supports the three most recent minor Kubernetes releases at any given time, following the same support window as Kubernetes upstream.

​
CNCF conformance

Any Kubernetes distribution that passes the CNCF Kubernetes Conformance test suite is expected to work with PGO. If you encounter a compatibility issue on a conformant distribution, please open an issue on the PGO GitHub repository.

​
OpenShift considerations

OpenShift enforces pod security through Security Context Constraints (SCCs). PGO detects whether it is running on OpenShift at startup by querying the openshift.io/ API group. When OpenShift is detected, PGO omits fsGroup and other security context fields that conflict with OpenShift’s restricted SCC. The log line connected to Kubernetes ... openshift=true confirms detection was successful.
If you deploy the reference monitoring stack (config/monitoring/) on OpenShift, you must comment out the fsGroup line in alertmanager/deployment.yaml, grafana/deployment.yaml, and prometheus/deployment.yaml before applying. Leaving it in place causes the pods to fail admission under the restricted SCC.

​
SCC requirements

PGO pods run as non-root users. The PostgreSQL container runs as UID 26 (the postgres system user). pgBouncer, pgAdmin, and the exporter containers run as UID 2. These UIDs are fixed in the container images and do not require elevated privileges or a custom SCC in most OpenShift configurations.

​
Namespace configuration

By default, PGO watches all namespaces in the cluster. You can restrict it to a single namespace or a set of namespaces using environment variables: Leave both variables unset to run PGO in cluster-wide mode (the default for most installations).
See installation with Kustomize for the full namespace configuration reference.

​
Leader election

When running multiple operator replicas for high availability, enable leader election by setting the PGO_CONTROLLER_LEASE_NAME environment variable to a valid DNS subdomain name. The operator uses the Kubernetes coordination.k8s.io/leases API to elect a leader.
PGO_NAMESPACE tells the operator which namespace to use for the lease object. It is automatically injected via the Downward API in the reference Kustomize installation.

​
Storage requirements

PGO requires PersistentVolumeClaims for PostgreSQL data, pgBackRest repositories, and optionally for WAL and tablespace volumes. Ensure your chosen StorageClass:
  • Supports ReadWriteOnce access mode (required for all PostgreSQL instance volumes).
  • Supports online volume expansion (allowVolumeExpansion: true) if you plan to use the AutoGrowVolumes feature gate.
  • Provides adequate IOPS for your PostgreSQL workload. For production use, prefer SSD-backed storage classes such as gp3 on AWS, pd-ssd on GCP, or managed-premium on Azure.

Install with Kustomize

Step-by-step installation including namespace and leader election configuration.

Install with Helm

Helm-based installation for environments that prefer Helm-based workflows.

TLS configuration

Configure TLS for PostgreSQL connections on any platform.

Components reference

Container images and open source components included with PGO.