PostgreSQL 19 RC 1: build an upgrade rehearsal

PostgreSQL 19 RC 1, announced on 15 October 2026, is a release candidate. Use it to rehearse compatibility, representative application behavior and recovery before making an adoption decision. A successful connection to a new server is only the beginning of that evidence. ^[1]

An upgrade rehearsal should be able to say no#

Imagine an illustrative service with a critical billing query, an extension used by a background job and a backup process owned by another team. The application smoke test connects and reads a row. None of those three dependencies has been exercised. Calling that a successful upgrade rehearsal makes the checklist look complete while the most expensive unknowns remain.

The useful output is an adoption record with explicit blockers. It can say that the application works on the candidate but one extension is not supported, that a representative query changed behavior, or that restore evidence is still missing. A refusal to adopt yet is a productive result when it identifies the next test and the person who owns it.

Keep release timing separate from this internal sequence. The announcement’s later candidate and general-availability dates are plans that can change. Your rehearsal should record the exact build tested, so a result for this candidate is not silently presented as a result for a later release. Recheck upstream status before any adoption decision. ^[1]

What does the announcement establish?#

The project says the candidate is expected to be mostly identical to the initial release, while further fixes may still be applied. It lists fixes involving REPACK, pg_plan_advice and parallel autovacuum, among other areas. These are release-testing signals, not a claim that every workload benefits or every extension is already compatible. ^[1]

The announcement plans another candidate for 12 November and general availability for 19 November 2026, subject to issues that could change the schedule. Treat those as project plans, not completed events. Our recommendation is to record the tested build explicitly so later fixes cannot be confused with the candidate your team actually evaluated. ^[1]

What belongs in the compatibility inventory?#

Start the inventory with the actual server version, extensions, drivers, collations, operational tooling and application assumptions. Give each dependency an owner who can confirm its target-version support. Keep unresolved items visible rather than reducing readiness to whether an empty database starts successfully.

The announcement points users of earlier PostgreSQL versions toward a major-version upgrade strategy. The pg_upgrade reference describes a tool for major upgrades and includes compatibility checks and environmental requirements. The version 18 reference cited here supplies background, not a complete procedure for version 19; execution requires the target-version documentation. ^[1][2]

Do not turn this article into a shell runbook for an unknown environment. Our review asks the team to select its migration method deliberately, document the versions and storage mode involved, and rehearse that exact method on an isolated copy. An untested command copied from a different major version is not an adoption plan.

What would an adoption record look like?#

Source: record the actual major and minor version
Target: record the exact PostgreSQL 19 candidate build
Method: chosen from target-version upgrade documentation
Dataset: isolated, approved rehearsal copy
Extensions: owner and compatibility evidence for each
Workload: named reads, writes and background operations
Recovery: tested restore path and decision after new writes
Decision: not ready until unresolved gates have owners and evidence

This is a review template, not a pg_upgrade command line. The correct commands depend on source and target binaries, extensions, operating environment and migration method. The PostgreSQL 18 references below explain general upgrade and backup concepts; they are not a substitute for the target-version procedure. The candidate announcement links the PostgreSQL 19 upgrade documentation. ^[1][2][3]

Assign owners before running the rehearsal. A database team may validate server startup while an application team owns query correctness and another team owns the extension package. Without named ownership, a missing result can be mistaken for someone else’s successful test. Keep “not tested” separate from “passed” in the record.

For the illustrative billing query, preserve its parameters, data shape and expected result. Compare correctness before measuring runtime. If the plan changes, retain both plans and relevant settings so an engineer can investigate the difference. Do not attach a release-wide performance conclusion to one query, especially when hardware, warm-up or concurrency also changed.

Which workload should the rehearsal exercise?#

Use representative application behavior, not just a successful connection. Our proposed test set includes important reads, writes, background work and operational tasks. Compare results for correctness first. If a query plan or runtime changes, preserve the query, parameters, data shape and relevant settings before attributing the change to the new release.

Separate feature exploration from regression testing. A team may want to try a new capability, but that is a different question from whether its existing workflow remains correct. Keep exploratory results in a separate section so an attractive demonstration does not obscure a failing production-critical operation.

Performance claims need a controlled comparison. Record the baseline, machine resources, cache conditions and repeated workload behavior. Without that setup, do not publish an improvement percentage or assume a faster demonstration predicts production savings. A rehearsal can be valuable even when it exposes an unresolved regression.

What recovery evidence should exist?#

PostgreSQL’s backup overview distinguishes SQL dumps, file-system-level backups and continuous archiving. Each has assumptions and trade-offs. The existence of a backup job does not tell your team whether it can recover the required data and configuration under its actual operating constraints. ^[3]

1. Restore into isolationDemonstrate that an appropriate backup can be restored and the expected application data can be inspected. Record the scope and any excluded components.
2. Rehearse the selected upgrade pathUse the documented source and target versions, extension set and method. Keep the outputs that establish compatibility or explain a failure.
3. Validate the application contractExercise the representative workload and compare correct results. Include operational tasks that are easy to omit from a narrow application smoke test.
4. Define recovery after new writesDecide how the team would handle writes made after cutover. Do not assume that pointing the application back to an old cluster reverses those writes.

The pg_upgrade reference also warns about trust in source-cluster superusers. Keep the rehearsal’s security context deliberate and use an appropriate isolated dataset. For staged change ownership, see modernization without a big-bang rewrite. For existing tenant boundaries, see Postgres row-level security. ^[2]

What happens if the new cluster has accepted writes?#

A rollback discussion before cutover is much easier than one during an incident. Once the new cluster accepts writes, the old cluster is no longer an automatically current alternative. Decide how the application stops or redirects writes, which data must be reconciled, and which recovery method the team has actually rehearsed. A DNS reversal is not a data-reconciliation strategy.

Keep feature exploration in a separate experiment. Trying an interesting capability can be valuable, but it should not change the workload used to establish that the existing application still behaves correctly. Otherwise a successful demonstration and a regression become tangled in the same result.

The next engineering action is small and concrete: select one important application operation, one dependency outside core PostgreSQL and one restore check, then record their outcomes on the exact target build. Expand from that evidence. A release candidate is an opportunity to discover incompatibility while there is time to investigate, not pressure to make an unfinished adoption decision.

PostgreSQL release-candidate questions#

Is PostgreSQL 19 generally available now?

The cited 15 October announcement describes RC 1. At the time of this analysis, the project’s general-availability date remains a plan subject to further issues and release decisions. Recheck the project announcement before adoption. ^[1]

Can an earlier major version use an ordinary minor update procedure?

The announcement directs earlier-version users toward a major-version upgrade strategy. Select a supported method and consult the target-version documentation for the actual procedure; do not infer compatibility from minor-update habits. ^[1]

Does a successful pg_upgrade check prove the application is ready?

No. Tool compatibility is one gate. Our proposed review also tests application behavior, extensions, operational workflows and recovery. A successful preliminary check does not establish the correctness of every query or production dependency. ^[2]

What is the most useful outcome of the rehearsal?

A documented adoption decision supported by compatibility, representative workload and restore evidence. Finding an unresolved blocker is useful too: keep it visible and assign an owner rather than treating an upcoming release date as a deployment deadline.