PostgreSQL 14 Reaches End of Life in November 2026 — Where Should You Migrate?

Each Version's Deadline, and Who Is Affected

PostgreSQL ships one major release per year and supports each version for 5 years, with the end-of-life date always falling in mid-November, which makes it easy to plan around well in advance. PostgreSQL 13 already reached end of life on 13 November 2025, and PostgreSQL 14 will reach end of life on 12 November 2026 — these two versions are the ones that need a decision first.

Version	Release Date	End of Life	Status
PostgreSQL 18	25 Sep 2025	Nov 2030	Fully supported
PostgreSQL 17	2024	Nov 2029	Supported
PostgreSQL 16	2023	Nov 2028	Supported
PostgreSQL 15	2022	Nov 2027	Supported
PostgreSQL 14	2021	Nov 2026	Running out of time
PostgreSQL 13	2020	13 Nov 2025	End of life

Move to 17 or 18?

Once a move is unavoidable, the next question is which version to move to. Jumping straight to the newest release is not always the right call, and picking the second-newest is not automatically the safe one either.

Choice	Best suited to	Remaining support life
PostgreSQL 17	Organizations that prioritize stability, have extensions or surrounding tooling that has not yet certified 18, and do not want to be early adopters	Until Nov 2029 (about 6 years)
PostgreSQL 18	Organizations that want the longest support runway per upgrade cycle, and that benefit directly from Async I/O, OAuth 2.0 or UUIDv7	Until Nov 2030 (about 7 years)

What PostgreSQL 18 Adds Over What You Are Running Today

If you choose to move to 18, here is what you actually gain, grouped by the impact it has on production workloads.

Group 1 — Async I/O and Performance Improvements

This is the group with the biggest production impact, because it affects every query that reads data from disk directly — with no application code changes required:

1. Asynchronous I/O Subsystem (AIO)

PostgreSQL 18 introduces a new I/O subsystem that works asynchronously — storage reads can be up to 3 times faster for sequential scans, bitmap heap scans and vacuum. It is tunable through the io_method parameter, which supports three modes: worker (the default), io_uring (recent Linux kernels only) and sync (the previous behavior).

2. Skip Scan for B-tree Multicolumn Indexes

Previously, if you had an index on (a, b) and a query searched with WHERE b = ? without specifying a, the planner had to fall back to a sequential scan because the index was unusable. Version 18 supports skip scan, which automatically skips over the values of the leading column — cutting query time substantially when the first column has low selectivity.

3. Parallel GIN Index Build

Building a GIN index (widely used for full-text search and JSONB) can now run in parallel — reducing reindex time in proportion to the number of workers, which matters for organizations with large JSON tables.

4. Planner Statistics Carried Through the Upgrade

Previously, after a major-version pg_upgrade you had to wait for a full fresh ANALYZE, and during that window query plans could be unusually slow. Version 18 preserves the existing statistics through the upgrade, so post-upgrade performance is stable from the first minute.

Group 2 — Authentication and Security

This group matters a great deal for organizations that want to connect PostgreSQL to their corporate Single Sign-On (SSO) system and raise the bar on database authentication and security:

1. Built-in OAuth 2.0 Authentication

PostgreSQL 18 supports OAuth 2.0 through a new auth method named oauth in pg_hba.conf — a game changer for organizations running Azure AD, Google Workspace, Keycloak or any other identity provider because there is no need to store passwords in the database and no need to sync user accounts between systems.

2. SCRAM Passthrough in postgres_fdw and dblink

Federated queries over postgres_fdw and dblink can now pass SCRAM credentials through without storing passwords in configuration files — reducing the risk of credential leaks.

3. md5 Authentication Is Deprecated

4. FIPS Mode Validation and TLS 1.3 Cipher Config

Adds FIPS-compliance validation for organizations that must meet government security standards, plus a new ssl_tls13_ciphers parameter for defining your own TLS 1.3 cipher suite.

5. SHA-2 in the pgcrypto Extension

Functions in the pgcrypto extension now support SHA-2 for storing password hashes in tables — replacing MD5, which is no longer considered secure by modern standards.

Group 3 — Developer Features That Change How You Design a Schema

1. UUIDv7() — Fixing the Cache Problem of UUIDv4

UUIDv4 (fully random) has long been a popular choice for primary keys, but it has a drawback: it scatters the B-tree index cache, because newly inserted IDs are not ordered by time — the database has to read index blocks spread all over the place, which gets slower and slower as the data grows.

PostgreSQL 18 adds the uuidv7() function, which orders UUIDs by timestamp, so inserts land in sequence like a sequence number, while the value remains a globally unique UUID. It also adds a uuidv4() alias for gen_random_uuid() for consistency.

2. Virtual Generated Columns by Default

Generated columns in PostgreSQL before version 18 had to be STORED — the value was computed and physically written to disk, wasting storage and slowing updates. Version 18 supports VIRTUAL as the default — the value is computed only at query time, with no storage cost.

Aspect	STORED (previous)	VIRTUAL (new)
Storage	Consumes disk space	No storage cost
Update Performance	Slow (rewrites to disk)	Fast (no write)
Query Performance	Fast (read directly)	Slightly slower (computed at query time)
Best for	Columns read often, updated rarely	General derived columns (e.g. full name)

3. Temporal Constraints — WITHOUT OVERLAPS and PERIOD

This is a feature ERP developers have been waiting for. Version 18 supports declaring WITHOUT OVERLAPS in a PRIMARY KEY or UNIQUE Constraint, and PERIOD in a FOREIGN KEY — for tables that store time-bounded data, such as:

• VAT rates effective for particular periods — preventing rates with overlapping validity ranges from being created
• Product prices tied to promotional periods — enforcing non-overlapping periods at the database level
• Employee salaries by period — preventing data inconsistency without writing your own triggers

Previously this required writing triggers or using the btree_gist extension, both of which are cumbersome. Version 18 handles it in standard SQL syntax.

4. RETURNING Supports OLD and NEW

The INSERT, UPDATE, DELETE and MERGE statements now support RETURNING OLD.* and NEW.* — retrieving both the before and after values in a single statement, which cuts database round trips for audit-trail logic.

Group 4 — Replication and High Availability

• Parallel streaming by default for CREATE SUBSCRIPTION — lower replication lag on systems with large transactions
• pg_createsubscriber --all creates logical replicas of every database in a single command
• Automatic idle replication slot cleanup via idle_replication_slot_timeout — solving the classic problem of a forgotten replication slot letting WAL fill the disk
• Logical replication conflict logging — write conflicts are recorded in pg_stat_subscription_stats, supporting a more precise disaster recovery strategy

Group 5 — Observability and Monitoring

• EXPLAIN ANALYZE shows buffer access automatically, without having to add the BUFFERS option yourself
• Index lookup count appears in the plan — you can see immediately how many times a query probed an index
• EXPLAIN ANALYZE VERBOSE reports CPU, WAL and average read stats — for finer-grained query tuning
• pg_stat_all_tables records the timing of each vacuum and maintenance operation
• Per-connection I/O and WAL utilization — pinpoint which session is consuming heavy I/O or WAL

What This Means for Organizations Running an ERP System

For organizations using PostgreSQL as the backend of an ERP system, there are several points to assess before deciding to upgrade:

ERP Module	Features that help	Impact level
Accounting (GL, AR, AP)	Async I/O + temporal constraints for VAT / exchange rates	High
Period close / reporting	Skip scan + parallel GIN + planner stats preservation	High
HR / Payroll	Temporal constraints for period-based salaries + UUIDv7	High
Warehouse	Async I/O for sequential scans over large tables	Medium
Authentication	OAuth 2.0 for organizations that already have SSO	Medium

Before You Upgrade — What to Prepare

1. Check your current version — run SELECT version(); on every server, both primary and standby
2. Switch md5 → SCRAM-SHA-256 first — in pg_hba.conf and password_encryption, to be ready for the future version that removes md5
3. Test your application against PostgreSQL 18 in staging — especially if you use complex triggers or stored procedures
4. Always back up before upgrading — take a pg_basebackup with a WAL archive, and review your disaster recovery plan before you start
5. Plan for page checksums — PostgreSQL 18 enables page checksums by default for new databases. If you pg_upgrade from an existing cluster without checksums, you need a migration plan
6. Check your extensions — every extension you use (pg_trgm, postgis, timescaledb and so on) needs a version that supports PostgreSQL 18

Why This Matters to Organizations Running Saeree ERP

Saeree ERP has used PostgreSQL as its primary database for more than 20 years — chosen back when it was still version 7.x and carried through to today, across more than 10 major releases. The arrival of version 18 has direct implications for our customers:

• Upgrading on a planned cycle — the Saeree team tests compatibility with PostgreSQL 18 in a staging environment before recommending that production customers upgrade on an appropriate cycle. We do not push anyone to upgrade the day a version ships
• Temporal constraints and master data — in Saeree ERP administrators can add, inactivate and set the valid from-to range of VAT rates, exchange rates and product prices themselves, with no patch required. That logic already runs at the application level; PostgreSQL 18 temporal constraints would let the same rules be enforced at the database level as well — reducing data errors over the long run
• OAuth + SSO — for customers who already run an SSO system (Azure AD, Keycloak and so on), it becomes possible to plan for consolidating database authentication into the central system in the future
• PostgreSQL 13 end of life — Saeree reviews every customer cluster running below version 14 and prepares an upgrade roadmap for them

Good and Poor Candidates for Moving to 18

Upgrade now	Assess before moving
Still on PostgreSQL 13 or older (already end of life)	Upgraded to PostgreSQL 17 within the last 6 months
Read-heavy workloads that rely on sequential scans / vacuum	Small systems already running on fast SSD storage
Planning to implement SSO for the database	Still using local password auth throughout the system
Starting a new project — pick PostgreSQL 18 from day one	Key extensions not yet compatible (older builds of PostGIS, TimescaleDB)
Want UUIDv7 for new primary keys	Legacy triggers that depend on md5 auth

PostgreSQL 18 is not an ordinary routine upgrade — it replaces the I/O subsystem in a way that affects every query that reads from disk, and it adds new tools such as OAuth, UUIDv7 and temporal constraints that will substantially cut the amount of custom code development teams have to write.

- Saeree ERP Team

Conclusion

1. If you are still on PostgreSQL 13 or older — plan the upgrade now, because there are no more security patches
2. Switch md5 → SCRAM-SHA-256 on any system still using it — get ready for md5 being removed in a future version
3. Test your application against PostgreSQL 18 in staging before upgrading production
4. Run the latest minor version (currently 18.4), not 18.0
5. For new projects — start on PostgreSQL 18 and design your schema around UUIDv7 + temporal constraints from the outset

If your organization runs Saeree ERP, or is planning an ERP system on PostgreSQL and wants to assess its upgrade readiness, the Saeree team is ready to advise on choosing a database, planning the upgrade, and disaster recovery. You can contact our consulting team directly.

References

• PostgreSQL 18 Released! — postgresql.org (25 September 2025)
• PostgreSQL Versioning Policy — postgresql.org
• Celebrating PostgreSQL 18 Release — EnterpriseDB
• PostgreSQL 18 Release Notes — postgresql.org