zalando/postgres-operator v1.15.0

Boggling Mole

on GitHub

Here's a new release of the Postgres Operator. Thanks to everyone who contributed with PRs, feedback, raising issues or providing ideas. For those asking for Postgres 18: We haven't yet included it into Spilo and you have to wait for the next minor release in Q1 2026.

Enhancements

• introducing a second PDB for critical operations e.g. to protect pods during boostrap phase (#2830, #2844)
• added support for Patroni's bootstrap_labels feature (#2872, #2875)
• ensure podAnnotations are removed from pods if reset in the config (#2826)
• inlcude service selector comparison to compareServices. Required when switching to kubernetes_use_configmaps (#2955)
• include external traffic policy comparison into service diffing (#2956)
• improved maintenanceWindows checks during major version upgrades and pod migrations (#2810, #2842, #2849)
• extended example RBAC in preparation to switch to configmap-based cluster management (#2961)
• upgrade to go 1.25.3 + updated dependencies (#2945, #2922, #2857)
• [UI] Remove deprecated WAL-E library and enable WAL-G backup support in UI backend (#2915)
• [Logical backup] try to get creds from gcp metadata if LOGICAL_GOOGLE_APPLICATION_CREDENTIALS is not set (#2837)

Bugfixes

• fix to not create duplicate secrets for rotation users (#2863)
• fix creation of secrets in other namespaces when using preparedDatabases and OwnerReference (#2912)
• do not remove publications of slots defined in manifest (#2868)
• streams section removal now deletes the stream resource (#2868)
• docs fixes (#2896, #2948, #2949)

Breaking changes

• Removed 1.9.0 helm chart releases

Important note on deprecated K8s Endpoints

⚠️ This is the last release to have kubernetes_use_configmaps disabled by default. This option has once been introduced to support deployments on OpenShift but will now become the standard for K8s, too. For clusters with replicas you cannot easily switch from using Endpoints to ConfigMaps without risking a split-brain scenario because Patroni would read DCS-related facts from both these resources at the same time during a rotation. There are two possible migration paths:

Migrate in-place

This migration path requires three steps to be deployed separately:

1. Scale in all your database clusters to only one primary pod. This can be achivied with the max_instances config option set to '1'. A config change requires an operator pod restart. Make sure every Postgres cluster is scaled in to one pod before proceeding.
2. Change the operator config again and enable kubenertes_use_configmaps. Check if extra ConfigMaps ('-config' and '-failover') are created. It will also trigger a pod rotation and, since there's only the primary left, it will cause downtime.
3. Revert step 1, so all clusters are scaled out again.
4. (Optional) Remove all the Endpoints the Postgres Operator has managed before. But they do not cause eny harm if you leave them.

If you do not want to migrate all your clusters at once you can try working with multiple Postgres Operators instances that use different configs but have a CONTROLLER_ID specified. By annotating the Postgres manifest with different controller ids, you could move a single cluster through the migration steps mentioned above.

Migrate via standby clusters

To reduce impact during the migration one can also do the following steps:

1. Set up a second Postgres Operator (+ CONTROLLER_ID specified) running with ConfigMaps
2. Create standby clusters to all Postgres resources (or one by one). The standbys would then be managed by the second operator using the annotation with the corresponding controller ID. Ideally, also copy all secrets of the source cluster beforehand to avoid connection issues later (see docs).
3. Stop writes on the source cluster and promote the standby cluster. Downtime depends mostly on the deployment time of your app to point to the new database cluster.

✔️ Docker image: registry.opensource.zalan.do/acid/postgres-operator:v1.15.0
✔️ UI Docker image: registry.opensource.zalan.do/acid/postgres-operator-ui:v1.15.0
✔️ Logical Backup Docker image: registry.opensource.zalan.do/acid/logical-backup:v1.15.0

Multi-arch image (arm):
✔️ Postgres Operator: ghcr.io/zalando/postgres-operator:v1.15.0
✖️ UI: ghcr.io/zalando/postgres-operator-ui:v1.15.0
✖️ Logical Backup: ghcr.io/zalando/postgres-operator/logical-backup:v1.15.0

✔️ Default Spilo image: ghcr.io/zalando/spilo-17:4.0-p3

Thanks to our contributors: @hughcapet, @FxKu, @idanovinda, @jopadi
@ggramal, @mortenlj, @Juneezee, @mjtrangoni, @remram44