Versioning policy

We always recommend that all users run the latest available minor release for whatever major version is in use.

PostgreSQL major releases include new features and occur roughly once every year. Beginning with version 10, a major release is indicated by increasing the first part of the version, e.g. 10 to 11. Before version 10, a major release was indicated by increasing either the first or second part of the version number, e.g. 9.5 to 9.6.

Major releases usually change the internal format of system tables and data files. These changes are often complex, so we do not maintain backward compatibility of all stored data. A dump/reload of the database or use of the pg_upgrade module is required for major upgrades.

Minor releases are numbered by increasing the last part of the version number. Beginning with version 10, this is the second part of the version number, e.g. 10.0 to 10.1; for older versions this is the third part of the version number, e.g. 9.5.3 to 9.5.4. The PostgreSQL team only adds bug fixes to minor releases. All users should upgrade to the most recent minor release as soon as possible. While upgrades always have some risk, PostgreSQL minor releases fix only frequently-encountered, security, and data corruption bugs to reduce the risk associated with upgrading. The community considers not upgrading to be riskier than upgrading.

A tentative schedule for upcoming minor releases can be found in the roadmap.

Upgrading to a minor release does not require a dump and restore; merely stop the database server, install the updated binaries, and restart the server. For some releases, manual changes may be required to complete the upgrade, so always read the release notes before upgrading.

PostgreSQL release support policy

The PostgreSQL project aims to fully support a major release for five years. After its end-of-life (EOL) month ends, a major version receives one final minor release. After that final minor release, bug fixing ceases for that major version.

After a release falls out of full support, we may (at our committers' discretion) continue to apply further critical fixes to the source code, on a best-effort basis. No formal releases or binary packages will be produced by the project, but the updated source code will be available from our source code control system.

This policy will be followed on a best-effort basis. In extreme cases it may not be possible to support a release for the planned lifetime; for example if a serious bug is found that cannot be resolved in a given major version without significant risk to the stability of the code or loss of application compatibility. In such cases, early retirement of a major version may be required.

End Of Life (EOL) dates

Version Current minor Supported First release date EOL date
10 10.4 Yes October 2017 October 2022
9.6 9.6.9 Yes September 2016 September 2021
9.5 9.5.13 Yes January 2016 January 2021
9.4 9.4.18 Yes December 2014 December 2019
9.3 9.3.23 Yes September 2013 September 2018
9.2 9.2.24 No September 2012 September 2017
9.1 9.1.24 No September 2011 September 2016
9.0 9.0.23 No September 2010 September 2015
8.4 8.4.22 No July 2009 July 2014
8.3 8.3.23 No February 2008 February 2013
8.2 8.2.23 No December 2006 December 2011
8.1 8.1.23 No November 2005 November 2010
8.0 8.0.26 No January 2005 October 2010
7.4 7.4.30 No November 2003 October 2010
7.3 7.3.21 No November 2002 November 2007
7.2 7.2.8 No February 2002 February 2007
7.1 7.1.3 No April 2001 April 2006
7.0 7.0.3 No May 2000 May 2005
6.5 6.5.3 No June 1999 June 2004
6.4 6.4.2 No October 1998 October 2003
6.3 6.3.2 No March 1998 March 2003