Two Months Until PostgreSQL 14 End of Life: Practice Recovery Before Upgrading
Some teams schedule database version upgrades without knowing how long it takes to roll back when things fail. If you are running PostgreSQL 14, the deliverable you need right now is not merely the name of a new version, but a transition plan that includes viable recovery. As of September 14, 2026, roughly two months remain until the official end-of-life date.
Confirmed Fact: Community Support and Hosting Contracts Are Different
The official PostgreSQL versioning policy supports major versions for five years, listing November 12, 2026, as the final release date for 14. This is the community support schedule. Upgrade windows, separate extended support, and pricing for managed services must be verified independently in your provider's documentation and contracts.
You must also distinguish between minor updates within the same major version and major upgrades. Applying the latest point release for 14 does not substitute for migrating to 15 or higher. Conversely, continuously postponing necessary bug fixes on your current version simply because you have a major migration planned is not advisable.
First Deliverable: A Dependency List Over Data Size
From here on, these are operational recommendations rather than official support policies. First, document on a single page each service's DB version, extensions and their versions, connection drivers, batch jobs, backup storage locations, and replication topology. Do not choose a target version simply because it is the newest; verify the actual hosting environment and extension support range together.
Assuming an upgrade will be fast just because the DB is small is insufficient. If extensions or queries used in business-critical paths—such as the first lookup after login or updating payment statuses—behave differently, the cutover can fail even if data copying takes very little time. The goal of this list is to uncover unowned dependencies.
Second Deliverable: Restoration Results Instead of Backup Success Messages
Restore a recent backup into an isolated environment and execute representative application read and write workflows. During this exercise, verify the connection target first to ensure no writes are routed to the production DB. Restored copies containing actual data must be handled within existing access control boundaries.
Separating the backup start time, restore completion time, and validation completion time ensures you do not confuse the time spent fetching files with the time required for the service to accept writes again. Rather than passing artificially small samples, measure the time using a restored copy close to production scale, and record cost and storage constraints.
Passing the pg_upgrade Check Does Not Replace Service Validation
The official pg_upgrade documentation explains that running with --check allows you to perform compatibility checks before the actual upgrade. External module compatibility must be reviewed separately, and shared libraries matching the new server are also required. Do not interpret the success of the check command alone as validation of your application queries and overall performance.
In particular, the --link mode carries the constraint that the old cluster cannot be used as-is once the new cluster starts. Choosing this method based solely on speed might eliminate your anticipated rollback path. Rehearse under the exact same conditions as the actual cutover method, and clearly define the point at which a restore-based rollback is required.
Criteria to Decide Before Resuming Writes
Write down success criteria in advance so that decisions are not improvised on the day of the cutover. For example, completing core API reads and writes, resuming batch processing without duplicate execution, matching business aggregation totals on key tables, and verifying replication status can all be assigned to specific owners. This is not an example intended to impose uniform metrics on every service.
Once writes begin on the new DB, returning to a previous backup introduces the problem of how to preserve changes made in the interim. Simply turning on the old server should not be treated as equivalent to rolling back without data loss. The acceptable scope of data loss and downtime must be agreed upon by service stakeholders.
Action Items for This Week and Counterarguments
If migrating every DB at once is difficult, measure the restore, validation, and rollback times using the single service with the fewest dependencies, and feed those results into planning for other services. Consolidating the owners, candidate cutover dates, and abort criteria in case of validation failure into a single document turns a project that only exists on a calendar into actionable work.
Counterarguments that ongoing product development is a more urgent priority are understandable. However, remaining uncertain about how to recover until the deadline approaches leaves you with fewer available windows for validation. This article does not advocate for the performance gains of a specific version nor does it represent the consensus of the entire community. It is an operational recommendation focused on being prepared to handle cutover failures rather than rushing to adopt the latest features.