Skip to content
Percona Documentation
Rate this page
☆ ☆ ☆ ☆ ☆
Thanks for your feedback
Thank you! The feedback has been submitted.

Get free database assistance or contact our experts for personalized support.

Get help from Percona

Percona Operator for PostgreSQL 3.1.0 has been released

Percona Operator for PostgreSQL 3.1.0 has been released on September 9, 2026.

This version establishes Percona Operator for PostgreSQL as a hard fork of the Crunchy PGO project , making it fully independent and empowering the Percona team and community to drive and rapidly deliver features and improvements tailored to user needs.

Try it out using the Quickstart guide.

New features and improvements introduced by this release include:

  • Encrypt data at rest with pg_tde. Tables, indexes, temporary files and WAL stay unreadable without the keys, even if storage is compromised. Enable pg_tde in the Custom Resource and configure HashiCorp Vault as the key provider. The Operator installs and configures encryption for you. Encrypted tables, backups, and restores work as usual once the Operator can reach the key. Available with PostgreSQL 17 and 18. See our documentation to learn more.

  • Keep logs after Pod restarts and configure log rotation. PostgreSQL and pgBackRest logs now persist across Pod restarts so that you have the trail you need for an incident. The Operator uses Fluent Bit to collect logs and stream them either as JSON lines or forward them to your custom destination such as S3 or OpenTelemetry. See our documentation to learn more. Also, tune log rotation in the Custom Resource so you keep enough history for troubleshooting or compliance without filling the disk.

  • Offload reads with declarative logical replicas. Point reporting or other heavy queries at a read-only replica in the same cluster instead of the primary. Declare the replica in the Custom Resource. The Operator creates the volume, copies the data, converts the physical replica to a logical one and exposes a dedicated Service. Patroni does not promote the logical replica so the endpoint stays stable. Requires PostgreSQL 17 or later. See our documentation to learn more.

  • Pause pgBouncer without dropping clients. Set proxy.pgBouncer.paused for a short window to restart PostgreSQL, run a switchover or drain backends. Active queries finish while new requests wait until you resume. The pause survives Pod restarts.

  • Grow backup storage before it fills. Automatic storage scaling now covers pgBackRest repository volumes, not only data volumes. The Operator watches usage and expands the PVC up to the limit you set, so a full pgBackRest repository volume no longer stops backups. See our documentation to learn more.

  • Mount extra files into PostgreSQL instances. Share full-text search dictionaries or other assets outside the data directory. Configure the volume once under instances.extraVolumes and every instance in the set sees the same mount. Use a ConfigMap, Secret, PersistentVolumeClaim, emptyDir, or another volume source that Kubernetes supports. See our documentation to learn more.

  • Fit PostgreSQL into your platform PKI. If you sync certificates from AWS Secrets Manager or External Secrets, a briefly missing Secret no longer makes the Operator generate a new CA and restart Pods. Set certManagementPolicy: userProvidedOnly so applications keep using the certificates already loaded. Learn more about TLS management policy in our documentation. For client mTLS, add your corporate CA to pgBouncer with additionalTrustedCAs while the Operator still rotates cluster certificates. Check the setup guide for the steps.

  • Support of UBI 8, 9 and 10 as the base image for PostgreSQL UBI 9 remains the default. Stay on UBI 8 for older extensions or Enterprise Linux 8, or move to UBI 10 to align with RHEL 10 and a longer support window. Treat a UBI change as an OS upgrade: collation and indexes can break until you reindex.

  • Run the Operator with community or your own PostgreSQL images. Point spec.image, pgBouncer, and pgBackRest at community tags or your private registry. The Operator manages the cluster the same way. Percona-only features such as pg_tde are not available on community images.

  • Evaluate PostgreSQL 19 (tech preview). Deploy Community PostgreSQL 19 now to test the next major version and plan your upgrade before GA.

  • RKE2 and full ARM64 support. Official RKE2 testing adds a new supported Kubernetes distribution. Full ARM64 images let you run natively on ARM-based cloud and edge clusters.

  • Deprecation, rename and removal:

    • Removed support for PMM2. This Operator release no longer supports PMM2 as it has reached the end-of-life state. Upgrade to PMM3 as soon as possible.

    • The extensions.builtin section is deprecated and will be removed after version 3.4.0. We encourage you to use extensions.<extension>.enabled. You can still use the old form during the transition. If both forms are set at the same time, extensions.builtin takes precedence.

    • pg_cron and set_user extensions have been added to the list of built-in extensions. Your existing setup via extensions.custom remains unchanged and works as expected after the upgrade. Reconfigure the extensions after you upgraded the database to ensure the cluster finishes each change in one pass. Switch to built-in extensions as follows:

    • Remove the extension from the extensions.custom list

    • Set extensions.pg_cron.enabled or extensions.set_user.enabled to true.

    You must do these two Custom Resource changes in the same apply so they land in one reconciliation loop. Removing the extension from extensions.custom alone instructs the Operator to delete it.

    • Field descriptions were removed from the inherited CrunchyBridgeCluster CRD (upstream.pgv2.percona.com/v1beta1). The object schema and cluster behavior are unchanged. Running kubectl explain for those fields no longer shows help text.

Learn more in Percona Operator for PostgreSQL 3.1.0 release notes.