PostgreSQL 19 Is Still an RC. Start the Upgrade Rehearsal

A major database upgrade is not a package update. It is a change in storage engine behavior, query plans, extension compatibility, replication and recovery procedures. PostgreSQL 19 has reached Release Candidate 1, which gives operators a concrete build to evaluate while the project continues toward its planned November 19 final release.

The project released RC1 on October 15 and published a schedule targeting November 19 for the final release, subject to change. Release candidates are intended for testing; they are not a signal to move production workloads. Before acting on a feature description, check the current release notes and release announcements again because both timing and details can still change. ^{[1] [4]}

Still, this is a practical window for rehearsals. Teams can check extensions and drivers, compare query behavior, estimate migration time and confirm that backups restore before a deadline arrives.

Maintenance work is moving closer to the operator

The PostgreSQL 19 release notes describe REPACK and REPACK CONCURRENTLY operations for replacing table storage, parallel autovacuum work across table indexes, and prioritization behavior for vacuum work. The exact command semantics and restrictions deserve a careful read before you plan around them. A feature name is not a maintenance runbook. ^[2]

The release notes also describe changes around logical replication sequence values, standby “read your writes” behavior through WAIT, and COPY support. For teams operating replicated applications, these changes can affect where they wait for consistency and which data movement path is most convenient. The right question is not just whether a command exists; it is whether its guarantees fit the application’s recovery and latency needs.

Those capabilities make an upgrade rehearsal useful even before GA. Pick one representative service and a sanitized production-sized copy. Run the existing maintenance schedule, replication failover, backup restore and application integration checks. Measure how long the new path takes and record new operational assumptions in the runbook.

Rehearse the migration method, not just the SQL

PostgreSQL’s upgrade documentation describes several ways to move a cluster between major versions, including pg_upgrade, dump and restore, and replication-based approaches. Each has different downtime, storage, compatibility and rollback tradeoffs. The method should be chosen for the cluster and its availability requirements, not because a previous team used it elsewhere. ^[3]

Start with the full dependency list: server extensions, client drivers, logical replication consumers, backup tools, monitoring queries and any application code that depends on planner behavior or system catalog details. Confirm which versions are supported by the exact RC build you test. Run representative read and write traffic, not only the migration itself.

The rehearsal should end with a verified restore and a rollback decision. If the team cannot restore the source snapshot, compare row counts and key constraints, validate replication catch-up, and return the application to service, it has not completed the test. Avoid destructive experiments on production data; use a copy whose provenance and refresh date are recorded.

Treat RC testing as feedback, not a promise

The best near-term outcome is a short list of validated changes, open incompatibilities and owners. A team might test whether its autovacuum workload improves, whether new replication semantics simplify a consumer, and whether a query plan regresses under real statistics. It should also keep a precise record of the build tested so that results are not accidentally attributed to a later release candidate.

PostgreSQL 19 is close enough to plan around, but still in motion. Use the RC to expose risk while there is time to fix it. Wait for the final release and its documentation before setting a production upgrade date, then repeat the checks against the actual release artifact. A disciplined rehearsal turns a release announcement into operational evidence.