On 15 October 2026, the PostgreSQL team announced the availability of PostgreSQL 19 RC1. At the time of writing, it is a release candidate intended for testing, and the announcement advises against running it in production. I see this stage as an opportunity to check compatibility and prepare an upgrade plan grounded in the nature of the application and its data.
Testing that resembles everyday use
For a case-processing system, I would start with the most frequent and most consequential operations: looking up an application, displaying its action history, opening a periodic report, and updating a status tied to a permission. The comparison is run on test data that reflects real volumes and relationships, without using sensitive information that is not needed.
I also want the testing to cover multiple users and concurrent requests, not just the time taken by a single query. The everyday experience is shaped by waiting, contention and errors as much as by the speed of a successful operation. It helps to record the measurement conditions so that the comparison between the two environments is fair.
Compatibility checklist before the change window
I review the extensions in use, the connection drivers, the backup tools, scheduled jobs and the relevant application settings. Then I try the chosen upgrade path in a separate environment and record the time taken and any observations. A database that starts successfully does not prove that every report and integration works as expected.
- Compare results, constraints and key relationships before and after the upgrade.
- Check concurrent operations, error messages and heavy reports.
- Test a restore and confirm that the application can return to service.
- Define the point at which to stop, and who owns the decision, during the change window.
The support timeline shapes the plan
The release announcement also notes that support for PostgreSQL 14 ends on 12 November 2026. That matters for anyone running that version, but it does not mean jumping to a release candidate. A suitable supported path is chosen according to the versioning policy, the compatibility results and the operational requirements.
The rollback plan should, I suggest, describe what happens to data written after the cutover. Going back is not simply a matter of switching a connection if the data or the storage format has changed. It therefore has to be tested, and its limits reviewed, before the upgrade is carried out, with a clear agreement on acceptable downtime and on how communication will be handled.
What matters to me in following a new release is preparing early: knowing what works, what needs adjusting, and what evidence is required before approving a change that affects a live service.