Skip to content
EOL Watch
Search itemsOpen menu

AzureEnd of support

Azure Database for PostgreSQL: PostgreSQL 16 end of standard support

Azure Standard Support End Date for PostgreSQL 16 on Azure Database for PostgreSQL: 9 Nov 2028. Once the Azure Standard Support period ends, eligible servers still running the version are automatically enrolled in extended support.

Support ends , 9 Nov 2028

What breaks

Once the Azure Standard Support period ends, an eligible server still running PostgreSQL 16 is automatically enrolled in extended support. The eligible versions table lists PostgreSQL 11, 12, 13 and 14.

  • Extended support provides security patches, critical bug fixes and technical support for up to three extra years. It does not include new features, performance enhancements or support for minor version upgrades.
  • Charges apply after any applicable grace period unless the server is upgraded to a supported version, and only to servers in a Succeeded (running) state. A one-month grace period is provided for versions 11, 12 and 13. A server that regional capacity constraints prevent from upgrading might be temporarily excluded from billing.
  • The version policy page lists restrictions that apply after the retirement date of a version, without stating whether that date is 9 Nov 2028: new servers cannot be created on a retired version, while point-in-time recoveries and read replicas of existing servers remain possible.
  • The same page says that when the community retires a version, Azure stops applying bug or security patches to the database engine. The extended support page lists security patches and critical bug fixes as part of extended support.

Who is affected

Affected versions

  • 16

Matching resource types

  • microsoft.dbforpostgresql/flexibleservers
  • azurerm_postgresql_flexible_server

Fields the check reads

  • pgversion
  • version

Detected by the estate check from

  • Azure Resource Graph export (CSV or JSON)
  • Terraform state or plan (JSON)
  • ARM template

Check your estate for this

What to do

  1. Run the upgrade validation checks in the Azure portal or with the Azure CLI. See Run upgrade validation checks.
  2. Resolve any blocking issues the checks report, then rerun validation.
  3. Ensure the server has at least 10-20% free storage available before starting the upgrade.
  4. If the server uses geo-replication, delete the read replica (including any cascading read replica) before upgrading the primary server. The replica can be re-created after the upgrade.
  5. Run an in-place major version upgrade to a PostgreSQL version that Azure currently supports. The service can skip versions and upgrade directly to a later version. Servers that use TimescaleDB are limited to specific source and target version combinations, and an upgrade from PostgreSQL 11 first requires SCRAM authentication to be configured. Once the server runs a supported version, extended support charges no longer apply. See Major version upgrades.
  6. Plan for the fact that there is no automated way to revert after a successful upgrade. A point-in-time recovery to a time before the upgrade restores the previous version on a new server.

Replacement

Not stated by vendor.

Sources

Last checked against the first source in this list on .

Found an error? Report it

The text on this page is drafted with AI assistance from the vendor's text, checked against the official source and approved by a person before it is published. How items are written

Last checked · Added · Changelog for this item