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.
Percona Operator for PostgreSQL 2.9.0
PostgreSQL 18 Is Now the Default
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.
Major Version Upgrades Are Now Generally Available (GA)
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.
PVC Snapshot Backups: Faster Backups and Restores (Tech Preview)
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:
- Significantly faster backup and restore operations for large volumes
- Point-in-time recovery is supported when combined with pgBackRest WAL archiving
- Currently supports cold (offline) backups only. We will add a hot snapshot (online) in a future release.
- Requires enabling the
BackupSnapshots feature gate
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.
WAL Lag Detection for Standby Clusters
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.
LDAP Authentication Support
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:
- Simple bind – the user’s distinguished name (DN) is constructed from a template and used directly to bind
- Bind-and-search – the Operator first binds with a service account, searches for the user’s DN, then re-binds with the user’s credentials
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.
Automated TLS Certificate Management via cert-manager
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:
- cert-manager automatically renews certificates 30 days before expiration
- Configurable validity periods let teams align certificate lifecycle with their security policies
Overall, this makes it straightforward to enforce encrypted-in-transit policies across all PostgreSQL clusters without operational overhead.
Official PostGIS Docker Image
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.
Operational Improvements:
pprof Profiling for Troubleshooting
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.
Custom DNS Suffix Configuration
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.
Volume Mounting for Sidecar Containers
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.
Configurable Operator Leader Election
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:
- Use the PGO_CONTROLLER_LEASE_DURATION, PGO_CONTROLLER_RENEW_DEADLINE, PGO_CONTROLLER_RETRY_PERIOD – environment variables to adjust timing for lease acquisition and renewal.
- Use the PGO_CONTROLLER_LEADER_ELECTION_ENABLED – environment variable to turn on or off leader election for single-replica deployments
- Use the PGO_CONTROLLER_LEASE_NAME – environment variable to use a custom Lease resource for a leader lock.
Configurable wal_level
You 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.
Deprecations and Breaking Changes
PMM2 Support Deprecated
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 Removed
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 Default
The 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.
Conclusion
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.
About the Author
Slava SarzhanSenior Cloud Engineering Manager from Lviv, Ukraine, with a passion for building smarter, more efficient Kubernetes solutions. I joined Percona in January 2019, starting as a build/release engineer managing Jenkins farms and automating testing and release processes. Soon after, I moved to the cloud team, creating testing infrastructure and developing new features for Kubernetes operators. Over the years, I’ve grown into leadership, guiding distributed engineering teams to deliver scalable, production-ready solutions while fostering a culture of ownership, clarity, and continuous improvement. Kubernetes isn’t just a tool for me, it’s a playground for innovation. I focus on solving complex problems, improving systems, and sharing insights with the community.
