PostgreSQL 14 Has Different Support Deadlines in the Cloud
An estate spanning self-managed PostgreSQL, Azure flexible server and Amazon RDS can have three different dates on the same planning sheet. The community’s final release is due on 12 November 2026. Azure Database for PostgreSQL flexible server lists 11 December 2026 as its standard support end. Amazon RDS for PostgreSQL lists 28 February 2027. The right deadline depends on where each database runs and which support terms actually cover it.
The PostgreSQL versioning policy still lists 14 as supported, with 14.24 its current minor release, as checked on 30 September. It says a major version becomes unsupported after its final minor release. The November date is a published plan, not evidence that the final release has already shipped. PostgreSQL’s 14.24 notes, published on 13 August, already urge users to move to a newer branch.
The service determines the support boundary
| 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 11 December 2026 | 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. |
These dates come from the PostgreSQL project, Microsoft’s Azure support table and Amazon’s RDS release calendar. They describe different maintainers’ commitments. A self-managed installation does not inherit an RDS or Azure extension. Nor should a managed customer assume the community date means the database service shuts down that day.
Both providers describe extended support beyond their standard periods, but it is a bridge with its own terms. Microsoft says its offer covers security patches, critical bug fixes and technical support, while excluding new features, general bug fixes and minor version upgrades. Amazon describes paid RDS Extended Support with security updates for critical and high severity vulnerabilities, critical fixes and support. Its calendar puts PostgreSQL 14’s first Extended Support pricing date at 1 March 2027. Check the applicable enrolment, charges and engine version before using either service as a reason to defer migration.
A current patch does not complete the major upgrade
Running 14.24 matters now. The project recommends the current minor release, and its 14.24 notes include security fixes and migration cautions. They say a dump and restore is unnecessary for an upgrade within 14.x, but some configurations or indexes may need attention. Installing 14.24 does not move the database to a supported major version after the community’s November boundary.
The PostgreSQL upgrade guide treats a major move differently: data must be moved by a logical dump and restore, pg_upgrade, or a suitable replication method. A filesystem-level backup cannot stand in for a logical dump when using dump and restore across major versions. New releases can also change SQL behaviour and client compatibility. For Azure, Microsoft specifically warns that non-core extensions are not automatically upgraded with the engine.
Prove the route out of 14
Give every PostgreSQL 14 instance an owner and a short evidence record:
- 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.
If migration cannot finish before the applicable standard support boundary, record the precise provider bridge, its scope, cost and expiry alongside a dated upgrade plan. The November community deadline is a reason to start that proof now, even where a managed service provides more time.
Sources
- PostgreSQL versioning policy, current table checked 30 September 2026; no page revision date shown.
- PostgreSQL 14.24 release notes, released 13 August 2026; checked 30 September.
- PostgreSQL major upgrade guide, checked 30 September; no page revision date shown.
- Azure Database for PostgreSQL flexible server extended support, page last updated 14 July 2026; checked 30 September.
- Amazon RDS for PostgreSQL release calendar and RDS Extended Support overview, checked 30 September; no publication or revision date shown on these pages.
