Crunchy Data announces the release of Crunchy Postgres for Kubernetes 5.0.4.

Crunchy Postgres for Kubernetes is powered by PGO, the open source Postgres Operator from Crunchy Data. PGO is released in conjunction with the Crunchy Container Suite.

Crunchy Postgres for Kubernetes 5.0.4 includes the following software versions upgrades:

  • PostgreSQL versions 14.1, 13.5, 12.9, 11.14, and 10.19 are now available.
  • PostGIS version 3.1.4 is now available.
  • pgBackRest is now at version 2.36.
  • PgBouncer is now at version 1.16.
  • The pgAudit extension is now at version 1.6.1.
  • The pgnodemx extension is now at version 1.2.0.
  • The pg_partman extension is now at version 4.6.0.
  • The TimescaleDB extension is now at version 2.5.0.

Read more about how you can get started with Crunchy Postgres for Kubernetes. We recommend forking the Postgres Operator examples repo.


  • The JDBC connection string for the Postgres database and a PgBouncer instance is now available in the User Secret using jdbc-uri and pgbouncer-jdbc-uri respectively.
  • Editing the password field of a User Secret now changes a password, instead of having to create a verifier.


  • PostGIS is now automatically enabled when using the crunchy-postgres-gis container.
  • The Downward API is mounted to the database containers.
  • pgnodemx can now be enabled and used without having to enable monitoring.
  • The description of the name field for an instance set now states that a name is only optional when a single instance set is defined.


  • Fix issue when performing a restore with PostgreSQL 14. Specifically, if there are mismatched PostgreSQL configuration parameters, PGO will resume replay and let PostgreSQL crash so PGO can ultimately fix it, vs. the restore pausing indefinitely.
  • The pgBackRest Pod no longer automatically mounts the default Service Account. Reported by (@Shrivastava-Varsha).
  • The Jobs that move data between volumes now have the correct Security Context set.
  • The UBI 8 crunchy-upgrade container contains all recent PostgreSQL versions that can be upgraded.
  • Ensure controller references are used for all objects that need them, instead of owner references.
  • It is no longer necessary to have external WAL volumes enabled in order to upgrade a PGO v4 cluster to PGO v5 using the “Migrate From Backups” or “Migrate Using a Standby Cluster” upgrade methods.