PostgreSQL End of Life - Dates and Lifecycle

First released in 1996 as a successor to the original POSTGRES project, PostgreSQL has grown into one of the most widely deployed relational databases in production, running everything from single-tenant SaaS backends to multi-petabyte analytics platforms. That scale of deployment means PostgreSQL's end of life schedule directly affects a large share of production data infrastructure, and a database is one of the harder pieces of a stack to upgrade quickly once its version falls behind.

PostgreSQL Lifecycle Explained

The PostgreSQL Global Development Group supports each major version for exactly five years from its initial release date. During that window, minor releases containing bug fixes and security patches ship at least once every three months, with out-of-band releases issued sooner if a critical issue can't wait. There's no separate "LTS" tier in PostgreSQL: every major version gets the same five-year window and the same level of support throughout, then goes end of life on the same terms.

A new major version ships roughly once a year, so at any given time there are typically five supported major versions in the field alongside several that have already gone end of life. Once a version hits its five-year anniversary, the development group ships one final minor release containing any outstanding fixes, and after that the version receives nothing further, security patches included. Major version upgrades also require a dump and reload or the use of pg_upgrade, since the on-disk format changes between major versions, which is part of why organizations tend to fall behind PostgreSQL's schedule more easily than with software that supports simpler in-place updates.