clusterdatabase-as-a-servicedata-infrastructuregolangkubernetesmanaged-servicesoperatorpostgrespostgres-operatorpostgresql
When a Postgres cluster has a finalizer, deleting it sets a DeletionTimestamp but doesn't remove the object until the finalizer is cleared. The operator was not properly handling these DeletionTimestamp changes: 1. postgresqlUpdate() was filtering out events where only DeletionTimestamp changed (it only checked Spec and Annotations), causing the delete to never be processed. 2. EventUpdate case in processEvent() didn't check for DeletionTimestamp, so even if the event reached the processor, it would run Update() instead of Delete(). 3. removeFinalizer() used a cached object with stale resourceVersion, causing "object has been modified" errors. Fixes: - Add explicit DeletionTimestamp check in postgresqlUpdate() to queue the event - Add DeletionTimestamp check in EventUpdate to call Delete() when set - Fetch latest object from API before removing finalizer to avoid conflicts |
||
|---|---|---|
| .github | ||
| charts | ||
| cmd | ||
| docker | ||
| docs | ||
| e2e | ||
| hack | ||
| kubectl-pg | ||
| logical-backup | ||
| manifests | ||
| mocks | ||
| pkg | ||
| ui | ||
| .flake8 | ||
| .gitignore | ||
| .golangci.yml | ||
| .zappr.yaml | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| MAINTAINERS | ||
| Makefile | ||
| README.md | ||
| SECURITY.md | ||
| build-ci.sh | ||
| delivery.yaml | ||
| go.mod | ||
| go.sum | ||
| mkdocs.yml | ||
| run_operator_locally.sh | ||
README.md
Postgres Operator
The Postgres Operator delivers an easy to run highly-available PostgreSQL clusters on Kubernetes (K8s) powered by Patroni. It is configured only through Postgres manifests (CRDs) to ease integration into automated CI/CD pipelines with no access to Kubernetes API directly, promoting infrastructure as code vs manual operations.
Operator features
- Rolling updates on Postgres cluster changes, incl. quick minor version updates
- Live volume resize without pod restarts (AWS EBS, PVC)
- Database connection pooling with PGBouncer
- Support fast in place major version upgrade. Supports global upgrade of all clusters.
- Pod protection during bootstrap phase and configurable maintenance windows
- Restore and cloning Postgres clusters on AWS, GCS and Azure
- Additionally logical backups to S3 or GCS bucket can be configured
- Standby cluster from S3 or GCS WAL archive
- Configurable for non-cloud environments
- Basic credential and user management on K8s, eases application deployments
- Support for custom TLS certificates
- UI to create and edit Postgres cluster manifests
- Compatible with OpenShift
PostgreSQL features
- Supports PostgreSQL 17, starting from 13+
- Streaming replication cluster via Patroni
- Point-In-Time-Recovery with pg_basebackup / WAL-G or WAL-E via Spilo
- Preload libraries: bg_mon, pg_stat_statements, pgextwlist, pg_auth_mon
- Incl. popular Postgres extensions such as decoderbufs, hypopg, pg_cron, pg_repack, pg_partman, pg_stat_kcache, pg_audit, pgfaceting, pgq, pgvector, plpgsql_check, plproxy, postgis, roaringbitmap, set_user and timescaledb
The Postgres Operator has been developed at Zalando and is being used in production for over five years.
Supported Postgres & K8s versions
| Release | Postgres versions | K8s versions | Golang |
|---|---|---|---|
| v1.15.0 | 13 → 17 | 1.27+ | 1.25.3 |
| v1.14.0 | 13 → 17 | 1.27+ | 1.23.4 |
| v1.13.0 | 12 → 16 | 1.27+ | 1.22.5 |
| v1.12.0 | 11 → 16 | 1.27+ | 1.22.3 |
| v1.11.0 | 11 → 16 | 1.27+ | 1.21.7 |
| v1.10.1 | 10 → 15 | 1.21+ | 1.19.8 |
Getting started
For a quick first impression follow the instructions of this tutorial.
Supported setups of Postgres and Applications
Documentation
There is a browser-friendly version of this documentation at postgres-operator.readthedocs.io

