Understanding PostgreSQL Versioning: A Guide for DBAs

PostgreSQL is a powerful, open-source relational database management system (RDBMS) widely praised for its standards compliance, extensibility, and reliability. For database administrators (DBAs), understanding how PostgreSQL versions are structured and maintained is essential—not only for ensuring compatibility and security, but also for planning upgrades and managing diverse environments.

In this post, we explore PostgreSQL’s versioning history, current numbering scheme, release cycle, and support policy—vital knowledge for any DBA working in production.

Why PostgreSQL Versioning Matters

Every PostgreSQL version brings enhancements in performance, security, and features. Understanding the versioning model helps DBAs:

• Apply the correct patches and updates.
• Understand what level of support a version receives.
• Plan for timely upgrades to avoid running unsupported software.
• Maintain consistent behaviour across development, staging, and production.

PostgreSQL Version Numbering Explained

PostgreSQL has used two main versioning schemes in its history:

1. Before PostgreSQL 10: Three-Part Versioning

Prior to version 10, PostgreSQL used a three-number format:

Major.Minor.Patch
Example: 9.6.3

• Major (9): Significant releases that introduced large changes.
• Minor (6): Minor feature additions and improvements.
• Patch (3): Bug fixes and security patches.

This model provided detailed version control but led to some confusion, especially when minor versions introduced new features.

2. PostgreSQL 10 and Beyond: Two-Part Versioning

From version 10 onwards, PostgreSQL adopted a more streamlined two-part format:

Major.Minor
Example: 10.3

• Major (10): Indicates a major release. New features, architectural changes, or major improvements.
• Minor (3): Indicates a minor update, typically containing security patches, stability improvements, and bug fixes.

Note: In this format, there is no longer a separate “patch” version. Bug fixes and patches are now included in the minor release.

Example Versions and What They Mean

PostgreSQL Release Cycle and Support Policy

Understanding the PostgreSQL release cadence and support timeline is crucial for planning upgrades and ensuring continued security compliance.

1. Major Releases

• PostgreSQL delivers a new major version every September.
• Major versions introduce new features, architectural changes, and performance improvements.
• Upgrading between major versions requires tools such as pg_upgrade, or migration via logical replication (e.g., pg_dump and pg_restore).

2. Minor Releases

• Minor versions are released every three months.
• These contain security patches, bug fixes, and minor enhancements.
• Minor upgrades are non-disruptive and can usually be applied in-place without requiring a database dump or restore.

3. Long-Term Support (LTS) Policy

Each major version of PostgreSQL is supported for five years from its initial release.
After this period, the version reaches End of Life (EOL) and no longer receives updates or security fixes.

All releases have followed a similar pattern.

Final Thoughts

If you’re managing PostgreSQL in production, knowing the versioning scheme and release policy isn’t just a nice-to-have; it’s essential for staying secure, stable, and future-ready. The two-part versioning format introduced in PostgreSQL 10 makes it easier to track updates, while the regular release cadence ensures continued innovation and reliability.

In the next post, we’ll cover upgrade strategies, including how to assess risk, prepare for migrations, and choose between in-place and logical upgrades. Feel free to contact if you think we can help you manage  your PostgreSQL environment.