PGO: Postgres Operator for Kubernetes
/postgres-operator
PGO: The Postgres Operator from Crunchy Data turns PostgreSQL cluster management into a Kubernetes custom resource you declare, reconciling failover, TLS, and backups automatically. Reach for it if your team runs stateful workloads on Kubernetes and wants Postgres HA and disaster recovery built in; skip it if you'd rather keep Postgres off Kubernetes or want a fully hosted database instead of an operator you run yourself.
Managing PostgreSQL with PGO
PGO: The Postgres Operator from Crunchy Data is a Kubernetes operator that manages PostgreSQL clusters through custom resources instead of shell scripts. You describe the cluster you want โ replica count, storage, TLS, backup schedule โ in a PostgresCluster object, and PGO's controller loop reconciles the live cluster against that spec, wiring in Patroni for failover and pgBackRest for backup and restore.
Who Benefits from Crunchy Data's PGO?
Platform and infrastructure teams that already run stateful workloads on Kubernetes and need to provision many PostgreSQL clusters the same way, repeatedly, are the clearest fit for PGO. It also suits teams that want GitOps-style, code-reviewed database changes instead of someone SSHing into a box to run pg_basebackup by hand. Teams without Kubernetes operational experience, or those who just need one small database and don't want to learn CRDs, Patroni, and pgBackRest to get it, are better served by a managed database service instead.
Key Capabilities for Cloud Native Postgres
- โDeclarative cluster provisioning: create, scale, and delete PostgreSQL clusters by editing a PostgresCluster custom resource, with full control over Pod and PostgreSQL configuration, per the README.
- โHigh availability through a distributed consensus failover mechanism, tunable Pod anti-affinity, and automatic healing of failed primaries โ plus standby clusters that can span multiple Kubernetes clusters.
- โDisaster recovery built on the open-source pgBackRest utility, with full, incremental, and differential backups and efficient delta restores, per the README.
- โTLS enforced on every connection by default, with the option to bring your own TLS infrastructure instead of PGO's.
- โCluster health monitoring through the open-source pgMonitor library, backed by Prometheus, Grafana, and Alertmanager among the project's included components.
- โConnection pooling via pgBouncer, plus both asynchronous and synchronous replication modes for workloads that can't tolerate losing transactions.
- โCloning: spin up a new cluster from an existing cluster or its backups instead of restoring by hand.
- โBackup storage to local disk, S3, GCS, Azure Blob Storage, or a mix of locations at once, with configurable retention and schedules.
Installing the Postgres Operator
The README doesn't give a single all-in-one install command โ it points to a hosted Quickstart and Tutorials on Crunchy Data's documentation site as the primary path. The fallback it does spell out: fork and clone the postgres-operator-examples repository, then run `kubectl apply -k kustomize/install/namespace` followed by `kubectl apply --server-side -k kustomize/install/default`. That path installs PGO alongside Crunchy Data's own PostgreSQL distribution as 'Crunchy Postgres for Kubernetes,' which downloads container images from Crunchy Data's Developer Portal โ image use is subject to the separate Crunchy Data Developer Program terms, per the README. Running PGO against your own PostgreSQL containers instead requires modifying these steps and building those containers yourself; instructions for that live per-component under the components directory.
Advantages of Using PGO
- โCluster changes go through git-reviewable custom resources instead of imperative scripts, which fits a GitOps pipeline naturally.
- โDisaster recovery is pgBackRest under the hood, with delta restores and incremental/differential backups built in rather than assembled from separate tools.
- โTLS is on by default for every connection, not an opt-in you have to remember to configure.
- โMonitoring, pooling, and JIT compilation (via LLVM) ship as part of the included container components rather than requiring separate integration work.
- โApache-2.0-licensed source code with no proprietary core, and testing across seven named platforms including EKS, AKS, GKE/Anthos, OpenShift, Rancher, and VMware Tanzu.
Considerations for PGO Deployment
- โณThe documented install path pulls container images from Crunchy Data's Developer Portal under the separate Crunchy Data Developer Program terms โ going fully independent of that requires modifying the standard steps and building your own PostgreSQL containers per the components directory's per-piece READMEs.
- โณNo version number, release cadence, or roadmap appears in the README, so there's no way to gauge release frequency or maturity trajectory from the repo alone.
- โณDay-to-day operational detail โ resizing, upgrading, customizing configuration โ isn't documented inline in the README; it's deferred almost entirely to Crunchy Data's external Tutorials and reference docs.
- โณBuilding the container images yourself means working through separate README files per component in the components directory rather than one consolidated build guide.
Other Kubernetes Postgres Operators
PGO Frequently Asked Questions
PGO's source code is licensed Apache-2.0, per its GitHub repository. Container images pulled through the standard install come from Crunchy Data's Developer Portal, which carries the separate Crunchy Data Developer Program terms.
Crunchy Data's PostgreSQL containers bundle PostgreSQL itself with contrib modules, PL/Python, PL/Perl, PL/Tcl, pgAudit, pg_cron, pg_partman, pgnodemx, set_user, TimescaleDB's Apache-licensed edition, and wal2json, alongside pgBackRest, pgBouncer, pgAdmin 4, pgMonitor, Patroni, and LLVM for JIT.
Crunchy Data's Postgres Operator, PGO, undergoes testing across Kubernetes, OpenShift, Rancher, Google Kubernetes Engine (including Anthos), Amazon EKS, Microsoft AKS, and VMware Tanzu, per the README.
PGO's customization options let it point at a container registry you pick yourself, private repos included through imagePullSecrets, instead of Crunchy Data's default images โ custom PostgreSQL images are supported per the README.
PGO applies PostgreSQL updates through its upgrade management feature, described in the README as designed to minimize impact on cluster availability during the process; the exact upgrade mechanics live in Crunchy Data's Tutorials, not the repo README itself.
Crunchy Data hosts PGO's official documentation, including the Quickstart, Tutorials, and architecture references, at access.crunchydata.com โ the README links out to it rather than duplicating it.
The problem it solves
Running Postgres well on Kubernetes normally means separately wiring up a failover framework, a backup tool, a connection pooler, TLS certificates, and a monitoring stack, then keeping all of that working as clusters get resized or migrated. PGO's README frames its purpose around collapsing that stitching work into a single operator: one PostgresCluster resource reconciles Patroni-backed failover, pgBackRest backups, pgBouncer pooling, and pgMonitor observability together, instead of a team assembling and maintaining each piece on its own.
Best use cases
- โขStandardizing how a platform team provisions PostgreSQL for many application teams, so every cluster gets the same HA, backup, and TLS defaults through one CRD instead of one-off scripts per team.
- โขRunning Postgres with automated failover on Kubernetes for production workloads that can't tolerate a manual failover process.
- โขBuilding backup and disaster-recovery pipelines to S3, GCS, or Azure Blob Storage through pgBackRest's scheduled full, incremental, and differential backups.
- โขCloning a production cluster's data into staging or dev environments from an existing cluster or backup instead of running a manual restore.
- โขRunning standby clusters across multiple Kubernetes clusters for cross-region disaster recovery, per the README's multi-cluster standby support.
How to use
Day to day, you work with PGO by editing the PostgresCluster custom resource rather than running imperative commands: the README describes resizing container resources and storage 'at any time' with minimal disruption, pointing PGO at a container registry you pick yourself (private repos included, via imagePullSecrets), and adjusting PostgreSQL configuration directly through its customization reference. Namespace scope is also configurable โ PGO can watch every namespace in the cluster or be restricted to specific ones. The README doesn't walk through a full example PostgresCluster YAML inline, so field-by-field usage is best learned from Crunchy Data's Tutorials rather than this repo alone.
Related repositories
Is postgres-operator worth your time?
ChatGPT, Claude and Perplexity can all read this page. Ask one of them what it makes of postgres-operator.