Your application can keep working after its database loses community support, leaving the upgrade decision easy to postpone. The PostgreSQL project announced on 12 November 2026 that PostgreSQL 14 had reached end of life, with no further community security or bug fixes for that branch.
For the technology lead, the useful decision is which migration route the team can prove safe for its own application. That means naming the outage it can tolerate, the evidence needed before reopening writes, and the recovery action if the new database fails afterwards.
The approach below is our operational recommendation for a team running its own database. A managed service may prescribe different tools or offer separate extended support; ask the provider to confirm the applicable procedure and terms.
Put PostgreSQL 14 EOL on a concrete change plan
Keep immediate patching and the major upgrade as separate work items. PostgreSQL's final branch release notes include migration cautions about potentially affected indexes and rebuilding C-language extensions for full protection against composite-type issues. Have the database maintainer read those notes against the installed extensions before approving the patch.
For the major upgrade, record the application owner, database owner, hosting arrangement, extensions, background jobs and connected systems. Ask each owner how the application will be tested on the destination. A successful connection alone is weak evidence: a shipment screen may load while a scheduled export fails.
Choose the target from versions supported by the application, extensions and hosting platform. PostgreSQL's upgrade documentation says a direct jump between major versions is possible, but instructs readers to review the intervening major release notes for compatibility changes. The application owner should turn that review into named acceptance tests.
Choose a route from a measured rehearsal
PostgreSQL documents dump and restore, pg_upgrade, and replication as upgrade routes. A physical copy of the old data directory is not a substitute for the logical dump used to move between incompatible major versions.
Use this decision table as a starting point for the rehearsal:
| Route | Consider it when | Evidence to request before approval |
|---|---|---|
| Logical dump and restore | The business can accommodate the measured transfer and restore window | A complete restore, application checks and elapsed time with production-like data |
| pg_upgrade | The installed extensions and environment permit the documented procedure | Compatibility checks, a timed rehearsal and an explicit choice of file-transfer mode |
| Logical replication | The team needs to reduce the final interruption and can operate parallel databases | A tested subscription, coverage of unsupported objects and a rehearsed stop-write and catch-up sequence |
Do not accept a timing estimate based only on database size. Our recommendation is to measure the full period during which users cannot complete work, including validation and the decision to reopen access. Record who can extend the outage and who tells operations if the rehearsal exceeds the agreed window.
For a small internal application with a workable maintenance window, start by testing the simplest supported route. For a busy order system, request evidence that the proposed route fits its workload. The database owner should attach the rehearsal result to the change request before a production date is booked.
Check the gaps before choosing logical replication
Replication adds work beyond copying rows. PostgreSQL's logical replication restrictions state that schema changes, sequence state and large objects are not replicated automatically. A receiving table can contain the expected rows while its sequence still needs adjustment before accepting new inserts.
Ask the maintainer how each of those gaps is handled in this application. Include schema deployment order, sequence alignment and a separate treatment for any large objects in the rehearsal. Freeze unrelated schema changes during the cutover period unless the migration plan explicitly covers them.
Consider an illustrative warehouse application: staff create shipments, a worker imports orders, and a reporting integration reads completed deliveries. Use this hypothetical application to define acceptance tests. The migration test should prove that a shipment can be created after cutover and that the next order import neither fails nor repeats completed work.
Assign the application owner to sign the workflow checks and the database owner to sign the replication checks. If either cannot explain the remaining gap, keep writes on the original system and resolve it before scheduling the switch.
Define the rollback boundary before starting
The file-transfer mode matters. PostgreSQL's pg_upgrade instructions provide a compatibility-only check and describe the recovery differences between modes. In link mode, the clusters share data files: after the new cluster has started, PostgreSQL warns that using the old cluster is unsafe and requires restoring it from backup. The boundary occurs before users necessarily make a business change.
Separately, treat the first accepted business write on the destination as a data decision. Our operational warning is simple: an untouched old copy no longer contains all current business activity once new writes exist elsewhere. Pointing the application back would omit those changes unless the team has a tested method to recover or reconcile them.
Write the recovery choice into the change request. Before destination writes, specify the safe return procedure for the selected migration mode. After destination writes, specify who may stop the service, preserve the new data and approve reconciliation or forward repair. Do not improvise reverse replication during an incident.
The technology lead should reject any rollback plan that ends with “switch the connection back” without describing the state of the data and the chosen migration mode.
Make reopening writes an explicit approval
Use a short checklist during the rehearsal and the real cutover:
- The application owner lists every writer, including workers, scheduled imports and administrative tools, and confirms each is paused.
- The database owner confirms the final transfer or replication catch-up is complete and records the recovery boundary reached.
- The application owner runs agreed read checks and controlled write tests, recording which tests changed destination data.
- Operations confirms that the critical workflow works and the named approver authorises normal traffic.
- The maintainer checks subsequent imports, scheduled jobs and application errors before closing the change.
These checks are our suggested operating procedure; adapt them to the service. Read validation and write validation belong in distinct steps because a write test can itself cross the boundary in the recovery plan.
If post-upgrade checks uncover an index problem, use a separate diagnostic procedure. Our guide to waiting, stopping or retrying a PostgreSQL concurrent index build covers that narrower decision. The application owner should keep unrelated maintenance outside the upgrade approval.
Approve the rehearsal before approving production
Ask for a change record containing the target, chosen route, measured outage, acceptance results and recovery decision. Missing evidence is a reason to run the rehearsal again, with a specific failed check to resolve.
Start with the database maintainer and the operations owner: agree which business workflow must survive and who can stop the cutover. Then use the backup and restore test checklist to record an actual recovery test before approving the production move.
Sources
- PostgreSQL Global Development Group, final branch release announcement and EOL notice (2026): release announcement.
- PostgreSQL Global Development Group, final branch migration cautions (2026): release notes.
- PostgreSQL documentation, maintained edition (2026): Upgrading a PostgreSQL Cluster, pg_upgrade and Logical Replication Restrictions. Checked 15 November 2026; confirm the instructions for your selected destination release.
