PostgreSQL 19 is a release candidate: what a Patroni upgrade should check

PostgreSQL 19 RC1 is out, RC2 lands 12 November and general availability is planned for 19 November 2026. A planning checklist for a Patroni-managed cluster.

By the Maborak engineering team · 2026-10-29 · 4 min read

PostgreSQL 19 RC 1 was released on 15 October 2026. The PostgreSQL Global Development Group plans a second release candidate on 12 November, alongside the scheduled update release, and general availability on 19 November 2026. Until then 19 is a candidate, not a production target.

Checked 29 October 2026. The dates and the changes listed below come from the PostgreSQL 19 RC 1 announcement. This is upgrade planning, not a feature review; confirm details against the release notes for the exact build you deploy.

The schedule

The release team delayed general availability to fold in fixes from the November update release. Treat those dates as the project’s plan, not a guarantee.

What the candidate already contains

The RC 1 announcement lists the fixes applied since Beta 4, which is evidence of what is still changing rather than a feature list:

• fixes for REPACK (CONCURRENTLY);
• fixes for pg_plan_advice;
• fixes to query-planner optimizations that depend on whether an expression can be NULL;
• fixes to automatic logical replication when wal_level is replica;
• a fix so postgres_fdw statistics import runs as the owner of the foreign table;
• fixes for parallel autovacuum;
• a fix so COPY (query) TO ... (FORMAT json) uses the query’s column names as JSON keys.

The point for planning is that several of these touch the planner, vacuum and logical replication. Those are the areas most likely to change behaviour under an existing workload, so they belong in a test plan rather than a release-day surprise.

A major upgrade, whatever the tooling

A major version upgrade from 18 or earlier requires either pg_upgrade or a dump and restore; the announcement points to the upgrading chapter for 19. A Patroni cluster does not change that requirement. Patroni starts, stops and fails over PostgreSQL according to the cluster configuration; it does not remove the need to run a major-version upgrade on each data directory.

A practical sequence:

1. Test on a copy first. Run pg_upgrade --check against a restored copy of the cluster and record the reported problems. The check mode is the cheap way to find missing modules, incompatible types and path assumptions before a maintenance window.
2. Inventory what is outside the data directory. Extensions and their shared libraries, custom types, pg_upgrade binaries for both the old and new major versions, and any data that lives in files the database references. pg_upgrade carries the catalogue; it does not install extension packages.
3. Decide the topology change. Upgrading standbys in place means the cluster is unavailable for writes during the work, or must run with logical replication side by side for a lower-downtime move. Record the choice, the expected write downtime and the rollback point before starting.
4. Keep the old cluster. A copy of the old data directory and its configuration is the rollback. A logical-replication move keeps the old primary readable until the cutover is confirmed.

Patroni-specific checks

• Confirm every node runs the same PostgreSQL major version before and after; Patroni will not present a mixed cluster as healthy.
• The DCS (etcd, Consul or ZooKeeper) holds cluster state. Plan the switchover so the new primary is the node you upgraded and verified, not whichever node wins an election.
• PgBouncer and other poolers in front of the cluster need to be drained and re-pointed. A pooler that still holds a session on the old primary can hide a failed cutover.
• Replication slots and their retained WAL are a capacity decision, not only an upgrade decision. An old slot that is not used after the move keeps holding WAL.

Acceptance checks

Before declaring the upgrade done, verify a normal connection, an authenticated write, a representative analytical query, a backup and a restore, and a switchover. Compare query latency and autovacuum behaviour with the pre-upgrade baseline. The release announcement lists planner and vacuum changes; measured comparison is how you establish that they did not regress your workload.

If the target is production, wait for the general-availability release on 19 November and the matching update release. Running a release candidate in production moves the release team’s remaining fixes into your incident budget.

The primary references are the PostgreSQL 19 RC 1 announcement, the 19 release notes and the upgrading chapter.

Topics: databases, migration, sre