We are excited to announce Percona Operator for PostgreSQL 2.9.0! In this release, we bring significant improvements across database lifecycle management, security, backup/restore, and operational observability, making it easier than ever to run production PostgreSQL on Kubernetes.
Here’s a deep dive into what’s new.
Starting with this release, PostgreSQL 18 is the default version for new cluster deployments. In addition, PostgreSQL 18 delivers improved query planning, better parallelism, enhanced logical replication, and many security hardening improvements.
If you’re still running PostgreSQL 13, please note that it has reached end-of-life and is no longer supported. We strongly recommend upgrading to a supported version (14 through 18) as soon as possible.
The following PostgreSQL versions are supported in Percona Operator for PostgreSQL 2.9.0: 14.22-1, 15.17-1, 16.13-1, 17.9-1, and 18.3-1. Other versions may also work, but they have not been officially tested or validated.
The major upgrade workflow for PostgreSQL clusters has graduated to General Availability (GA). After extensive testing across upgrade paths and Kubernetes environments, this feature is now production-ready. Specifically, major upgrades allow you to move your cluster to a newer PostgreSQL major version, for example, from PostgreSQL 16 to 17 or 18, with minimal disruption (in-place upgrade), all managed by the Operator. As a result, this removes the need for manual pg_upgrade procedures and complex migration scripts, letting you keep your clusters up to date with confidence.
One of the most exciting additions in 2.9.0 is PVC (Persistent Volume Claim) snapshot support for backups and restores. Rather than streaming data through pgBackRest, PVC snapshots leverage your storage layer’s native snapshot capability, dramatically reducing backup time, especially for large databases.
Key benefits of PVC snapshot backups:
Combined with pgBackRest’s full, differential, and incremental backup types, PVC snapshots give you the flexibility to build a layered backup strategy, routine incrementals for day-to-day protection, and near-instant snapshots before high-risk operations like major upgrades or schema changes, all managed by the same Operator.
This feature is in Tech Preview in 2.9.0. We encourage users to test it in non-production environments and share feedback via the Community Forum or GitHub issues.
Managing standby clusters just got smarter. The Percona Operator for PostgreSQL now supports WAL lag detection: when a standby cluster falls behind the primary by more than a configurable threshold, the Operator automatically marks its pods as unready, and the cluster enters an “Initializing” state with a StandbyLagging condition.
As a result, stale standbys from serving traffic silently, improving the reliability of high-availability setups and giving operators clear visibility into replication health. Your team no longer has to guess why something looks wrong. The Operator automatically detects lagging replicas.
Security teams can now enforce centralized user authentication for PostgreSQL through their corporate LDAP directory. The Operator’s new LDAP support allows you to configure PostgreSQL to authenticate users against an LDAP server directly, without requiring manual pg_hba.conf management.
Two authentication methods are supported:
LDAP integration enables teams to enforce the same identity governance policies for their Kubernetes-hosted PostgreSQL clusters as they do for the rest of their infrastructure. This means no more manually editing pg_hba.conf, no per-cluster credential management, and no separate offboardin, when a user is removed from LDAP, their access to PostgreSQL is gone instantly, across every cluster.
Managing TLS certificates for PostgreSQL clusters is now fully automated with cert-manager integration. With this integration, the Operator can automatically request, renew, and rotate TLS certificates for cluster communication, eliminating the need to manually manage certificate expiry or rotation scripts.
Highlights:
Overall, this makes it straightforward to enforce encrypted-in-transit policies across all PostgreSQL clusters without operational overhead.
Geospatial workloads on Kubernetes just became easier to manage. Furthermore, this release introduces an official PostGIS Docker image maintained by Percona, providing a supported and regularly patched path for running PostGIS 3.5.5 alongside PostgreSQL. With this addition, geospatial PostgreSQL deployments are now a first-class citizen in the Percona Operator ecosystem.
When diagnosing performance issues in the Operator itself, you can now enable pprof profiling by setting the PPROF_BIND_ADDRESS environment variable on the Operator pod. Doing so exposes Go’s built-in profiling endpoints, enabling CPU and memory analysis without an Operator restart.
Running PostgreSQL clusters inside vcluster or environments with custom DNS configurations? The new clusterServiceDNSSuffix option lets you specify the DNS suffix used for service discovery, ensuring correct name resolution in non-standard Kubernetes networking setups.
Sidecar containers can now mount PersistentVolumeClaims, Secrets, and ConfigMaps directly. The result is a wider range of sidecar use cases, from log exporters needing persistent storage to monitoring agents requiring configuration secrets.
If you’ve ever seen the Operator crash-loop during a Kubernetes API server blip, for example, when your cluster autoscales and the API server briefly throttles requests, this one is for you.
In previous versions, the Operator’s leader election lease settings were hardcoded. When the API server became slow or temporarily unreachable, the lease wasn’t renewed in time, the Operator lost leadership, and immediately restarted, often in a loop. There was no way to tune the timeouts to match your infrastructure.
v2.9.0 fixes this with four new environment variables:
wal_levelYou can now configure the wal_level PostgreSQL parameter via the Operator. Particularly useful for clusters without logical replication, setting wal_level = replica reduces unnecessary WAL overhead and improves write performance.
Support for PMM2 is now deprecated as it approaches end-of-life. PMM2 will be removed in a future release (two releases from now). Therefore, we strongly encourage all users to migrate to PMM3 to continue receiving monitoring support and new features.
PostgreSQL 13 has reached upstream end-of-life and this release drops it. If you are still running PostgreSQL 13 clusters, please upgrade to a supported version before updating the Operator.
pg_stat_monitor Disabled by DefaultThe pg_stat_monitor is disabled by default now to prevent potential memory issues in production clusters. If you rely on this extension, you can re-enable it explicitly via the custom resource.
Percona Operator for PostgreSQL v2.9.0 is a enterprise level features release that continues to push the boundaries of what’s possible when running PostgreSQL on Kubernetes. From making PostgreSQL 18 the new default to introducing PVC snapshot-based backups that can complete in seconds regardless of database size, this release squarely targets speed, security, and operational confidence.
We encourage you to try Percona Operator for PostgreSQL v2.9.0, explore the full release notes, and share your feedback with the community. As always, you can reach us through the Community Forum or file issues on GitHub.
Resources
RELATED POSTS
