The PostgreSQL Global Development Group lists November 12, 2026, as the final release date for PostgreSQL 14. After the final release, the upstream project will stop shipping security patches and bug fixes for the 14.x series. PostgreSQL versioning policy
If you run a managed database, check your provider’s timeline too. Maintenance schedules, supported upgrade paths, and extended support terms vary by service. Confirm when your provider’s coverage ends and whether that date affects your patching or compliance requirements.
If PostgreSQL 14 is still in your stack, start with an inventory. Find out where it runs, which applications depend on it, and how much time you’ll need to rehearse the upgrade and recover if something breaks.
1. Find every PostgreSQL 14 server and assign an owner
Start with your cloud database inventory, deployment manifests, and self-managed hosts. Check production, staging, QA, and disaster recovery environments. A standby replica that only gets attention during a failover is easy to miss.
From an application connection or SQL client, run this command to check the version of the server you’re connected to:
SHOW server_version; For every PostgreSQL 14 instance, record:
- The environment
- The owning team and primary engineering contact
- Connected applications, including scheduled jobs and BI or reporting tools that query the database outside normal traffic hours
- Available maintenance windows
If an instance has no clear owner, assign someone to map its dependencies before scheduling changes.
2. Choose a target version your stack can support
Check which PostgreSQL major versions your hosting platform supports and how long each will receive upstream fixes. Then verify compatibility with the extensions, database drivers, and backup tools you rely on. If an application uses PostGIS, for example, confirm that the required extension version is available on your target platform before booking a maintenance window.
For self-managed deployments, pg_upgrade and dump-and-restore are two major upgrade paths. If you plan to use pg_upgrade, run pg_upgrade --check during rehearsal to identify issues the tool can detect before the upgrade. On a managed service, follow your provider’s documented upgrade path and confirm whether you can move directly from PostgreSQL 14 to your target version. PostgreSQL versioning policy
3. Rehearse the upgrade and define your rollback trigger
Rehearse with a representative copy of production data. Time the upgrade, test the application’s critical read and write paths, and run background jobs that execute less frequently. A successful login confirms basic connectivity. Run the nightly reporting job separately to check that it still has the permissions and extensions it needs.
Restore a backup in a test environment, record how long recovery takes, and compare the measured time with your recovery time objective (RTO). Before cutover, agree on two things:
- When to roll back. Define a measurable trigger, such as an application error rate above an agreed threshold or an upgrade that exceeds the maintenance window.
- How to handle post-cutover writes. If you redirect traffic to the old PostgreSQL 14 instance after the upgraded database has accepted writes, those transactions will be missing from the old instance unless you have a way to reconcile them.
Your action plan for this week
By the end of the week, aim to give every remaining PostgreSQL 14 instance an owner, a target version to validate, and a scheduled rehearsal date. If you only have time for one step today, verify the server version behind your primary production connection and confirm who owns the upgrade.
If your team has already moved off PostgreSQL 14, what took longer than you expected during the rehearsal?
Author’s note: I work in marketing at Advange and cover enterprise IT news for infrastructure and operations teams. I used AI assistance to draft and edit this post.
