Which Deadline Governs Your Database?
For PostgreSQL 14, the migration deadline depends on who supplies the fixes. An estate spanning self-managed databases, Azure flexible server and Amazon RDS must separate its support cover from the time needed to prove a working upgrade.
Correction, 17 October 2026: The Azure date below replaces 11 December 2026 in the original article. Microsoft does not date that table change. The other deadlines have been rechecked.
Three commitments, not three switch-off dates
| Where PostgreSQL 14 runs | Published standard support boundary | What to check |
|---|---|---|
| Community or self-managed build relying on community fixes | Final community release due 12 November 2026 | Who will supply fixes after the community stops, if anyone? |
| Azure Database for PostgreSQL flexible server | Azure standard support ends 31 January 2027 | Confirm the server’s support status, extended support terms and upgrade window. |
| Amazon RDS for PostgreSQL | RDS standard support ends 28 February 2027 | Confirm the instance’s minor version, Extended Support enrolment and cost. |
A self-managed installation does not inherit a cloud provider’s extension.
Before you commit
Microsoft’s extended support covers security patches, critical bug fixes and technical support, not new features, general bug fixes or minor version upgrades. Non-core extensions are not automatically upgraded with the engine. AWS’s paid RDS offer covers critical and high-severity security issues, critical fixes and support; its calendar puts PostgreSQL 14’s first Extended Support pricing date at 1 March 2027. Before deferring, verify the engine version, enrolment, charges, scope and expiry.
Community support is still active. The version policy lists 14.24 as current and the November date as the final-release plan, not a release already shipped. The 13 August 14.24 notes urge a newer branch. A minor patch can require configuration or index attention, although a dump and restore is unnecessary within 14.x; it does not extend the major version’s support.
Prove the route out
The major upgrade guide describes logical dump and restore, pg_upgrade or replication. A filesystem backup is not a logical dump for a cross-major restore; SQL and client behaviour can change.
Give each database a named owner and keep its evidence with a dated, five-step migration plan:
- Name the service and exact version. Record whether it is self-managed, Azure flexible server, RDS or another provider. Capture the running major and minor version, the provider’s current support status, the relevant contract and the next deadline. RDS tracks minor version support separately, so the major version date alone is insufficient.
- Choose a supported target. Check the target major version against the provider’s available upgrade paths and the application’s requirements. Read the intervening PostgreSQL release notes, even if the upgrade can skip versions.
- Inventory blockers. Test extensions, drivers, SQL behaviour, server settings, roles, replication slots and failover arrangements on the target. Confirm that each required extension has a compatible version and an upgrade procedure.
- Rehearse recovery and cutover. Select a migration method, prove a recoverable pre-change backup with a restore test, measure downtime or replication lag, and define the point at which writes move. Test a rollback or restore procedure appropriate to that method; do not assume a major upgrade can simply be reversed.
- Verify the running result. After cutover, check the server version, application queries, extension versions, replication and backups. Close the work only when the production instance and its support entitlement match the plan.
Sources and dates
All six primary pages rechecked on 17 October 2026, following the original 30 September checks: community versioning policy; 14.24 release notes, released 13 August; major upgrade guide; Azure extended support, displaying a 14 July page-update date; and the RDS calendar and Extended Support overview. The other pages show no page-revision date.
