Postgres Versions: Supported Releases, EOL Dates & Upgrades

What Is Postgres Versioning?

PostgreSQL uses a Major.Minor versioning format. Major versions introduce new features, while minor versions provide security patches and bug fixes. The PostgreSQL community officially supports a major version for 5 years from its release date.

Current postgresql release status:

PostgreSQL follows an annual release cycle. The current landscape of actively supported major versions includes:

Note: Older versions like 13 and below are officially end-of-life and no longer receive community security updates.

Versioning policy details:

• Major upgrades: Upgrading to a new major version (e.g., from 16 to 17) requires data migration, which can be accomplished seamlessly for most configurations using tools like pg_upgrade.
• Minor upgrades: Upgrading between minor versions (e.g., from 16.13 to 16.14) is highly recommended, requires no data migration, and is performed by simply updating the binaries.

Why Postgres Version Support Matters

There are several reasons to ensure the Postrges version used is supported.

Security Updates

Security updates are a primary reason to maintain current Postgres versions. Each new minor release addresses vulnerabilities that could be exploited by attackers. These updates are critical because database servers are frequent targets for breaches, and unpatched systems are often the weakest link in an organization’s security posture. The PostgreSQL community actively monitors and responds to security threats, releasing fixes as soon as vulnerabilities are discovered.

Impact of unsupported versions:

Neglecting to apply security updates can result in unauthorized data access, data corruption, or service outages. Even if your database is not exposed directly to the internet, attackers may exploit weaknesses through compromised application servers or internal networks.

Performance Improvements

PostgreSQL developers continuously work on optimizing the database engine. With each new release, performance improvements are introduced, ranging from better query planning to enhanced indexing and storage efficiency. These enhancements can result in faster response times, reduced resource consumption, and the ability to handle larger data sets or higher transaction volumes without hardware upgrades.

Impact of unsupported versions:

Staying on older versions means missing out on these improvements, which can lead to slower applications and increased operational costs. Over time, performance gaps widen as new releases introduce further optimizations.

Related content: Read our guide on PostgreSQL performance factors and ways to supercharge performance.

Feature Compatibility

As PostgreSQL evolves, new features are introduced that expand its capabilities. These may include support for new data types, indexing methods, procedural languages, or replication features. Staying on current versions ensures compatibility with modern development frameworks, extensions, and third-party tools, enabling teams to innovate and leverage the full potential of the database.

Impact of unsupported versions:

Running outdated versions can restrict access to these features, creating barriers to application modernization and integration. Incompatibility with new libraries or extensions can force teams to use workarounds or maintain legacy code, increasing maintenance overhead.

What Is the Current Version of PostgreSQL?

As of June 2026, the latest stable PostgreSQL release is PostgreSQL 18.4. The PostgreSQL Global Development Group also maintains supported update releases for earlier major versions, including PostgreSQL 17.10, 16.14, 15.18, and 14.23. These minor releases include security fixes and bug fixes, making them the recommended versions for production environments running those major releases.

PostgreSQL 19 Beta 1 is also available, but it is a preview release intended for testing rather than production use. Beta versions allow developers and administrators to evaluate upcoming features, test application compatibility, and report issues before the final release becomes generally available. For production systems, organizations should use the latest supported stable release and apply minor version updates promptly.

Because PostgreSQL versions change regularly, administrators should always confirm the latest release on the official PostgreSQL website before planning upgrades. Staying current with supported versions helps ensure access to security patches, bug fixes, performance improvements, and compatibility with modern tools and extensions.

PostgreSQL Version Release Timeline

PostgreSQL follows a predictable release timeline that helps organizations plan upgrades, testing, and long-term maintenance:

• A new major PostgreSQL version is typically released about once per year, usually around September. 
• Each major release introduces new capabilities, performance improvements, and architectural enhancements.
• Major upgrades often require planning, compatibility testing, and sometimes application changes.

After a major version is released, it receives official support for five years. During this support window, the PostgreSQL Global Development Group provides minor releases that include bug fixes and security updates. Minor releases are scheduled at least once per quarter, usually in February, May, August, and November, with additional unscheduled releases possible when critical security or stability issues need faster attention.

At the end of the five-year support period, a PostgreSQL major version reaches end-of-life, or EOL. Once a version is EOL, it no longer receives security patches, bug fixes, or maintenance updates. For this reason, organizations should begin upgrade planning well before the EOL date rather than waiting until support has already ended. Proactive planning gives teams enough time to test extensions, review application compatibility, update backup and replication processes, and schedule production migrations with minimal disruption.

A typical PostgreSQL version lifecycle looks like this:

Understanding this timeline is essential for database lifecycle management. Teams that track release dates and EOL deadlines can avoid rushed migrations, reduce security exposure, and keep their PostgreSQL environments stable, supported, and ready for future growth.

Postgres Versions History

The table below summarizes the latest supported PostgreSQL major versions and their current minor releases as of June 2026. The latest stable release is PostgreSQL 18.4, while PostgreSQL 14 remains supported but is approaching end-of-life in November 2026. PostgreSQL 13 and earlier versions are no longer supported and should be upgraded for production use.

How to Check Your Current Postgres Version

Knowing which PostgreSQL version is running in your environment is important for upgrade planning, security patching, and troubleshooting. PostgreSQL provides several simple ways to check the version, whether you have database access or only server access.

1. Using SQL

The most common method is to run the following query from any PostgreSQL client:

The output includes the PostgreSQL version number along with build information and platform details. For example:

If you only need the version number, use:

This returns a simplified result such as:

2. Using the psql Command-Line Tool

If the psql client is installed, you can check its version from a terminal:

Example output:

Keep in mind that this displays the client version. In most cases it matches the server version, but not always. To verify the database server version, connect to the database and run SELECT version();.

3. Checking the PostgreSQL Server Binary

On systems where you have access to the PostgreSQL installation, you can check the server executable directly:

Example output:

This method is useful when troubleshooting server installations or confirming which PostgreSQL version is installed on a host.

How to Upgrade Postgres Versions

Minor Version Upgrades

Minor version upgrades are the simplest type of PostgreSQL upgrade because they maintain compatibility within the same major version. For example, upgrading from PostgreSQL 17.8 to 17.10 typically requires only installing updated packages and restarting the database service. These releases contain security fixes, bug fixes, and stability improvements, but do not introduce changes that require database file conversion.

Before upgrading, create a current backup and review the release notes for any issues that may affect your environment. In most cases, administrators can upgrade using their operating system’s package manager or PostgreSQL distribution packages. Once the update is installed, restart PostgreSQL and verify the new version using SELECT version(); or SHOW server_version;.

Because minor releases are designed to be low risk, they should be applied regularly as part of routine database maintenance. Delaying minor updates can leave systems exposed to known vulnerabilities and bugs that have already been fixed in supported releases.

Major Version Upgrades

Major version upgrades involve moving from one PostgreSQL major release to another, such as PostgreSQL 16 to PostgreSQL 17 or PostgreSQL 17 to PostgreSQL 18. These upgrades provide access to new features, performance improvements, and architectural enhancements, but they require more planning because PostgreSQL does not support in-place upgrades of database files across major versions.

There are two primary upgrade methods:

• The first is pg_upgrade, which migrates existing data files to the new version and is often the fastest approach for large databases. 
• The second is a logical migration, which exports data using tools such as pg_dump and restores it into a new PostgreSQL instance. Logical migrations generally require more time but can simplify transitions between significantly different environments.

Before performing a major upgrade, test the process in a non-production environment. Verify application compatibility, extension support, backup procedures, replication configurations, and monitoring integrations. A typical major upgrade process includes:

1. Review release notes and compatibility requirements.
2. Back up all databases and configuration files.
3. Install the target PostgreSQL version.
4. Upgrade using pg_upgrade or a logical migration method.
5. Test applications, extensions, and database functionality.
6. Redirect production traffic to the upgraded instance.
7. Monitor performance and validate backups after deployment.

Organizations should begin planning major upgrades well before a version reaches end-of-life. Early preparation reduces migration risk, avoids unsupported software, and provides sufficient time to address compatibility issues before they affect production systems.

Best Practices for Postgres Versioning

Organizations using Postgres should consider the following best practices to ensure they stay on top of versioning requirements.

1. Plan Major Version Upgrades Early

Early planning for major version upgrades is essential to avoid running unsupported software. The PostgreSQL development team publishes end-of-life dates for each major version, giving organizations ample time to prepare. By monitoring these dates and aligning upgrade schedules with regular maintenance windows, organizations can reduce the risk of last-minute issues and avoid forced upgrades under pressure.

Advance planning also provides time to:

• Review new features
• Assess compatibility with applications and extensions
• Communicate changes to stakeholders. 

This minimizes surprises during the upgrade process and allows for smoother transitions. Early preparation ensures that your team can test thoroughly, address potential issues proactively, and maintain business continuity throughout the upgrade.

2. Test Before Upgrading Production

Every PostgreSQL upgrade should be tested in a staging or development environment before being applied to production systems. Testing helps identify compatibility issues with applications, extensions, drivers, backup tools, and monitoring systems. Even when an upgrade is expected to be straightforward, validating the process beforehand reduces the risk of unexpected downtime.

A test environment should closely match production in terms of PostgreSQL version, configuration, and workload:

• Run application tests, validate database performance, and confirm that replication, backups, and maintenance jobs continue to function correctly. 
• Document any issues discovered during testing so they can be resolved before the production upgrade window.

3. Maintain a Version Inventory

Organizations should maintain an up-to-date inventory of all PostgreSQL instances and their versions. This inventory should include production, staging, development, and disaster recovery environments. Knowing which versions are deployed makes it easier to identify systems approaching end-of-life and prioritize upgrade efforts.

A version inventory should also track key details such as server locations, applications that depend on each database, installed extensions, and support status:

• Regular reviews help prevent forgotten or unmanaged databases from falling behind on security updates. 
• Accurate inventory data supports better planning, compliance reporting, and lifecycle management.

4. Verify Backups Before Every Major Upgrade

Creating backups is an essential step before any major PostgreSQL upgrade, but simply creating a backup is not enough. Administrators should verify that backups are complete, recent, and recoverable. A backup that cannot be restored provides little protection if an upgrade encounters problems.

Before beginning a major upgrade:

• Perform a test restore in a non-production environment and confirm that the restored database functions correctly. 
• Verify backup retention policies, recovery procedures, and available storage capacity.

This validation process ensures that a reliable recovery path exists if the upgrade must be reversed or repeated.

5. Document a Rollback Plan

Every major PostgreSQL upgrade should include a documented rollback plan. While upgrades are generally successful when properly tested, unexpected issues can still occur. A rollback plan defines the steps required to return systems to their previous state if application failures, performance problems, or compatibility issues arise after deployment.

The plan should:

• Identify recovery procedures, required backups, decision criteria for initiating a rollback, and the team members responsible for executing each step.
• Include estimated recovery times and communication procedures for stakeholders. 

Having a clear rollback strategy reduces uncertainty during incidents and helps restore services quickly if an upgrade does not proceed as expected.

Stay on Supported Postgres Versions with the NetApp Instaclustr Managed Platform

Keeping PostgreSQL current—applying minor patches promptly and planning major upgrades before end-of-life—is far easier when version management is handled for you. The NetApp Instaclustr Managed Platform delivers a fully hosted and managed PostgreSQL service that runs 100% open source PostgreSQL in the cloud or on-premises, giving you a production-ready cluster backed by 24×7 expert support. Because the service runs true open source PostgreSQL with no proprietary features or lock-in, you get access to new PostgreSQL versions quickly while a dedicated team handles the operational overhead of maintenance and upgrades.

Key capabilities of the NetApp Instaclustr Managed Platform for PostgreSQL:

• Continuous maintenance and version upgrades: Instaclustr handles ongoing maintenance and PostgreSQL version upgrades for you, keeping clusters patched and current without manual intervention.
• 24×7 expert support: A team of PostgreSQL specialists is available around the clock to plan upgrades, resolve production issues, and guide migrations between major versions.
• Multi-region replication and high availability: Read replicas can be created in secondary regions to minimize latency and maximize uptime, helping reduce disruption during version upgrades, backed by an industry-leading 99.99% SLA.
• Enterprise-grade security and compliance: The platform meets GDPR, SOC2, ISO27001, and ISO27018 requirements and offers PCI-compliant solutions, ensuring security patches and controls are maintained as part of the managed service.
• Flexible, open source deployment: Provision via console, REST API, or Terraform and run in your own cloud account, Instaclustr’s account, or on-premises—on AWS, Azure, or Google Cloud—with built-in monitoring included.

Eliminate the burden of self-managed PostgreSQL and keep your databases on supported, up-to-date versions. Learn more about managed PostgreSQL on the NetApp Instaclustr Managed Platform.