PostgreSQL 14 End of Life in 2026: A Production Upgrade Plan Before November 12

If your production database still runs PostgreSQL 14, the important date is November 12, 2026. That is the version's final community release date. After it, PostgreSQL 14 stops receiving normal community bug fixes and security fixes.

The immediate action is not to rush a major upgrade this weekend. First, make sure PostgreSQL 14 is on the current minor release, 14.24, because PostgreSQL's August 13, 2026 update fixed 28 security vulnerabilities and more than 110 bugs across supported branches. Then treat the major-version migration as a rehearsed production change: inventory extensions and dependencies, choose a supported target version, test the upgrade method on a production-like copy, measure application compatibility and query performance, define validation, and keep a credible rollback plan.

A sensible sequence is:

Patch PostgreSQL 14
        ↓
Inventory the real production cluster
        ↓
Choose target version and upgrade method
        ↓
Rehearse on production-like data
        ↓
Validate extensions, queries and integrations
        ↓
Plan cutover and rollback
        ↓
Upgrade before November 12

This guide explains what each step should contain and why simply changing the database version number is not enough.

What happens to PostgreSQL 14 on November 12, 2026?

PostgreSQL's versioning policy supports each major version for five years after its initial release. During that support period, minor releases provide security fixes, bug fixes and data-corruption fixes.

The current support table lists:

After the final PostgreSQL 14 release, the database does not suddenly stop starting.

The risk is subtler and more important:

New PostgreSQL 14 security, bug and data-integrity fixes stop arriving from the PostgreSQL community.

A server can continue running while becoming progressively harder to defend and support.

For a production SaaS, ecommerce platform, ERP, booking system or internal business application, that is operational debt with a known deadline.

Why the August 2026 security release makes this more urgent

On August 13, 2026, the PostgreSQL Global Development Group released PostgreSQL 18.6, 17.11, 16.15, 15.19 and 14.24.

The official release announcement says the update fixes:

• 28 security vulnerabilities
• more than 110 bugs
• several issues that can require extra post-update steps involving parallel GIN index builds, __INLINE_CODE_0__ and __INLINE_CODE_1__

The same announcement explicitly reminds PostgreSQL 14 users to plan an upgrade before November 12.

Several August vulnerabilities affected PostgreSQL 14 before 14.24. For example, PostgreSQL's security advisory for CVE-2026-6471 says affected versions before 14.24 could allow a user with replication privilege to cause logical decoding to load an arbitrary file visible to the PostgreSQL operating-system account, potentially executing code as that account.

Another advisory, CVE-2026-14669, covers a heap-buffer-overflow issue in __INLINE_CODE_0__ affecting supported branches before the August fixes.

The implication is practical:

Do not wait for the major upgrade before applying the current PostgreSQL 14 minor release.

PostgreSQL itself recommends running the current minor release for a supported major version and considers minor upgrades less risky than continuing on an old minor version.

So if production is on __INLINE_CODE_0__, __INLINE_CODE_1__ or __INLINE_CODE_2__, the first project is:

old PostgreSQL 14 minor
        ↓
14.24

The second project is:

PostgreSQL 14
        ↓
supported major version

They are related, but they are not the same change.

Which PostgreSQL version should you upgrade to?

There is no universal rule that every PostgreSQL 14 deployment must jump directly to PostgreSQL 18.

The current community support windows are a useful starting point:

For many teams moving from 14 in 2026, PostgreSQL 17 or 18 will be the more sensible candidates because they avoid planning another major-version migration soon after this one.

But target selection should consider more than end-of-life dates.

Check:

1. extension compatibility
2. managed database/provider support
3. ORM and driver compatibility
4. backup tooling
5. replication tooling
6. observability agents
7. connection poolers
8. application SQL assumptions
9. operating-system packages
10. change-management appetite

A newer major version is not automatically a better target if one production-critical extension is not certified for it.

Why PostgreSQL 18 is attractive for a 14 migration

PostgreSQL 18 was released on September 25, 2025 and is currently supported through November 2030.

Its release notes include changes that are especially relevant to teams already touching their database architecture:

• asynchronous I/O for operations including sequential scans, bitmap heap scans and vacuum
• __INLINE_CODE_0__ improvements, including retention of most optimizer statistics
• skip-scan support for more uses of multicolumn B-tree indexes
• built-in __INLINE_CODE_0__
• virtual generated columns
• OAuth authentication support
• __INLINE_CODE_0__ and __INLINE_CODE_1__ values in __INLINE_CODE_2__

These are reasons to evaluate PostgreSQL 18, not reasons to promise a performance improvement before benchmarking your workload.

The upgrade project should not use marketing logic such as:

PostgreSQL 18 has asynchronous I/O, therefore our application will be faster.

Instead:

upgrade candidate
        ↓
replay representative workload
        ↓
compare latency / throughput / plans / resource use
        ↓
accept or tune based on evidence

First inventory the cluster you actually have

Many PostgreSQL upgrades fail in planning because teams inventory the database version but not the database environment.

Before choosing the cutover method, capture at least the following.

Server version

select version();

Installed extensions

select extname, extversion
from pg_extension
order by extname;

Extensions are one of the most important upgrade constraints because __INLINE_CODE_0__ cannot guarantee that external modules are binary-compatible with the target PostgreSQL version.

Pay attention to extensions such as:

• PostGIS
• pgvector
• TimescaleDB
• __INLINE_CODE_0__
• __INLINE_CODE_0__
• custom C extensions
• vendor-provided extensions

Do not assume that because the extension exists for PostgreSQL 18, your current version and upgrade path are automatically supported.

Database sizes

select
  datname,
  pg_size_pretty(pg_database_size(datname)) as size
from pg_database
where datallowconn
order by pg_database_size(datname) desc;

Database size influences:

• dump/restore duration
• storage required for rehearsal
• cutover duration
• validation strategy
• backup/restore time

Roles

select
  rolname,
  rolcanlogin,
  rolsuper,
  rolreplication
from pg_roles
order by rolname;

Also inventory:

• tablespaces
• replication slots
• publications/subscriptions
• physical standbys
• logical replication consumers
• __INLINE_CODE_0__
• __INLINE_CODE_0__
• SSL/TLS setup
• connection poolers such as PgBouncer
• backup jobs
• monitoring agents
• scheduled jobs
• application drivers
• ORM versions
• CI/CD database jobs
• reporting/BI connections

The production PostgreSQL cluster is an ecosystem, not just a data directory.

Choose the upgrade method from downtime and risk constraints

PostgreSQL's official upgrade documentation describes several major-version migration approaches, including logical dump/restore, __INLINE_CODE_0__, and replication-based strategies.

The right method depends mostly on:

• database size
• acceptable downtime
• infrastructure layout
• rollback needs
• operational expertise

Option 1: __INLINE_CODE_0__

__INLINE_CODE_0__ is usually the first method to evaluate for a conventional self-managed PostgreSQL major upgrade.

The PostgreSQL 18 __INLINE_CODE_0__ documentation says it can upgrade data files to a later major version without the full dump/restore process.

A useful preflight is:

pg_upgrade --check \
  -b /path/to/postgresql14/bin \
  -B /path/to/postgresql18/bin \
  -d /path/to/old/config \
  -D /path/to/new/data

The important word is __INLINE_CODE_0__.

Run compatibility checks during rehearsal, not for the first time inside the maintenance window.

Copy mode

Default copy mode leaves the old cluster untouched while copying data to the new cluster.

Advantages:

• simpler rollback characteristics
• old cluster remains available as a separate copy

Trade-off:

• additional time and disk space for large clusters

Link mode

__INLINE_CODE_0__ can make the upgrade much faster and use less disk space by hard-linking data files.

But PostgreSQL warns that once the new cluster has been started after a link-mode upgrade, the old cluster's linked data is no longer a clean rollback source.

So the apparent speed advantage changes the rollback design.

Clone mode

On supported filesystems, clone mode can provide copy-on-write behaviour with speed/disk advantages while avoiding some of link mode's destructive characteristics.

Do not assume your filesystem supports it. PostgreSQL documents platform/filesystem requirements.

Swap mode

PostgreSQL 18 also documents __INLINE_CODE_0__, which can be particularly fast for clusters with many relations, but it destructively modifies the old cluster once file transfer begins.

That makes it an advanced operational decision, not the default choice merely because it looks fastest.

Option 2: dump and restore

Logical dump/restore is conceptually clean:

PostgreSQL 14
   ↓ pg_dump / pg_dumpall
logical export
   ↓
PostgreSQL 18

PostgreSQL recommends using dump tools from the newer server version for major-version migration.

Advantages can include:

• clean logical rebuild
• straightforward separation between old and new clusters
• opportunity to remove some accumulated physical baggage

Trade-offs include:

• potentially long export/import time
• substantial downtime for large write-heavy systems if there is no more elaborate sync strategy
• sequence/role/global-object considerations

For a 5 GB application database, dump/restore may be perfectly reasonable.

For a multi-terabyte production cluster with a strict maintenance window, it may not be.

Option 3: replication-based migration

For systems that cannot tolerate a long stop-the-world migration, a replication-based approach may be appropriate.

Conceptually:

PostgreSQL 14 primary
        ↓
continuous data replication
        ↓
new PostgreSQL cluster
        ↓
catch up
        ↓
short write freeze / cutover
        ↓
applications switch

This can reduce cutover downtime, but it increases migration complexity.

You need to reason carefully about:

• schema migration order
• sequences
• DDL changes
• extension compatibility
• replication coverage
• cutover consistency
• reverse replication or rollback

Do not select a zero/low-downtime architecture unless the business downtime requirement justifies the extra operational risk.

Your managed PostgreSQL provider changes the procedure

If the database runs on Amazon RDS, Aurora PostgreSQL, Azure Database for PostgreSQL, Cloud SQL, Supabase, Neon or another managed service, do not blindly follow a self-managed __INLINE_CODE_0__ tutorial.

The provider controls part of the process.

Before scheduling anything, confirm the provider's current documentation for:

• supported source/target versions
• in-place major-version upgrade support
• extension support
• backup/snapshot behaviour
• read replicas
• downtime expectations
• rollback limitations
• parameter-group changes

The general PostgreSQL compatibility work still matters, but the infrastructure procedure can be provider-specific.

Rehearse the upgrade with production-like data

A production database migration should have a dress rehearsal.

The rehearsal should use:

• a recent production backup or anonymised production-scale copy
• matching extension versions
• realistic database size
• representative application code
• the intended PostgreSQL target version
• the intended upgrade method

Record actual timings:

backup/clone preparation
pg_upgrade --check
upgrade execution
extension update
post-upgrade scripts
ANALYZE / statistics work
application smoke tests
full validation

This converts a maintenance-window estimate from guesswork into evidence.

Test extensions before the maintenance window

__INLINE_CODE_0__ can validate many cluster-level compatibility conditions, but PostgreSQL explicitly notes that external module binary compatibility cannot be fully checked by __INLINE_CODE_1__ itself.

Create an extension matrix:

Also test extension update commands when required.

A database upgrade should not discover at 02:00 that the production server package repository does not contain the extension build you need.

Application compatibility needs its own test plan

A successful PostgreSQL server start does not prove the application is compatible.

Test:

• login/authentication
• create/update/delete workflows
• background jobs
• reporting queries
• migrations
• transactions
• connection pooling
• prepared statements
• bulk imports/exports
• scheduled database jobs
• full-text/search functionality
• JSON/JSONB-heavy code
• geospatial functionality
• replication consumers

Also review PostgreSQL release-note migration sections for each major version crossed.

A 14 → 18 migration crosses four major-version boundaries. Application-visible incompatibilities accumulated across 15, 16, 17 and 18 all matter.

Compare query plans, not just endpoint health

One of the more useful PostgreSQL 18 upgrade improvements is that __INLINE_CODE_0__ can transfer most optimizer statistics rather than starting with an almost entirely cold statistics picture.

But PostgreSQL's documentation also notes that not all statistics are transferred.

After the upgrade, __INLINE_CODE_0__ can instruct you to regenerate missing and cumulative statistics with commands such as:

vacuumdb --all --analyze-in-stages --missing-stats-only
vacuumdb --all --analyze-only

Your validation should include important production queries.

Capture before/after evidence for:

• latency
• execution plans
• index usage
• sequential scans
• buffer/cache behaviour
• CPU
• I/O
• locks
• connection pressure

Do not assume a newer planner makes every historical query faster.

A regression caught during rehearsal is tuning work.

A regression discovered after DNS/application cutover is an incident.

Plan a real rollback, not a sentence saying "restore backup"

A rollback plan must answer:

1. What condition triggers rollback?
2. At what time does the decision become irreversible?
3. What happens to writes accepted by the new cluster?
4. How long does rollback take?
5. Who has authority to trigger it?
6. How are applications pointed back to the old database?

The chosen __INLINE_CODE_0__ transfer mode changes the answer.

For example, copy mode can preserve the old cluster more cleanly than link/swap modes.

But even with an intact old cluster, this can happen:

new cluster starts
        ↓
application accepts 30 minutes of writes
        ↓
critical issue discovered

Simply starting PostgreSQL 14 again would lose those new writes.

That is why rollback is not only a backup question. It is a data divergence question.

Set a rollback decision window and understand what happens to new data during it.

A practical production validation checklist

Immediately after cutover, validate in layers.

Database layer

• PostgreSQL reports the expected target version
• extensions load and have expected versions
• databases and schemas exist
• roles and grants are correct
• expected row counts/sizes are plausible
• sequences are correct
• replication and backups are healthy
• scheduled jobs are enabled exactly once

Application layer

• health checks pass
• authentication works
• representative reads/writes work
• transaction-heavy workflows work
• workers/cron processes connect
• admin/reporting tools connect

Performance layer

• error rate normal
• p95/p99 latency acceptable
• CPU/memory/I/O reasonable
• connection counts/pool saturation normal
• slow-query profile understood
• autovacuum/analyze behaviour healthy

Operations layer

• backup succeeds on the new cluster
• restore procedure is updated
• monitoring dashboards target the new cluster
• alerting works
• old cluster cannot receive accidental production traffic

Do not declare success because the homepage loads.

What should you do if you cannot upgrade before November 12?

The best answer is still: finish the upgrade.

If a genuine blocker makes that impossible, treat continued PostgreSQL 14 operation as a temporary risk exception rather than a normal steady state.

Possible compensating controls while migration is underway can include:

• stronger network isolation
• minimising database roles and privileges
• removing unnecessary replication/superuser access
• tighter monitoring
• rapid vulnerability assessment
• limiting exposed integrations
• reducing the window until migration

These measures do not turn an unsupported database back into a community-supported database.

There are also commercial vendors offering support for end-of-life PostgreSQL versions, but that is a separate commercial support decision and should not be confused with PostgreSQL community support.

A 10-week upgrade plan before EOL

With November 12 approaching, teams still have enough time for a controlled project if they start now.

Weeks 1–2: inventory and patch

• move PostgreSQL 14 to current minor release
• inventory databases/extensions/roles/replication
• identify application owners
• choose candidate target version

Weeks 3–4: build target environment

• install target PostgreSQL
• install compatible extensions
• update drivers/tooling in a branch
• run __INLINE_CODE_0__ or test chosen method

Weeks 5–6: rehearse

• restore/copy production-like data
• execute full migration
• record timings
• run application test suite
• compare critical query plans

Weeks 7–8: fix and rehearse again

• resolve extension/application issues
• tune changed queries
• test backup and restore
• test rollback procedure

Weeks 9–10: production cutover

• freeze unrelated schema changes
• confirm maintenance communications
• take final backup/snapshot
• execute tested runbook
• validate in layers
• monitor closely

If your database is large, highly available or operationally complex, compressing this into the final week is avoidable risk.

What not to do

Do not stay on an old PostgreSQL 14 minor until the major upgrade

Patch to 14.24 first unless your provider has a different managed upgrade procedure.

Do not choose PostgreSQL 18 only because it has the longest support window

Verify extensions, drivers and operational tooling.

Do not run __INLINE_CODE_0__ for the first time in production

Use __INLINE_CODE_0__ and rehearse the full path.

Do not copy the old __INLINE_CODE_0__ wholesale

New major versions have changed defaults, renamed/removed settings and new behaviours. Reconcile configuration intentionally.

Do not ignore every release-note migration section between 14 and the target

A direct major upgrade can cross several sets of compatibility changes.

Do not optimise for the shortest possible downtime at any cost

A more complex replication or destructive transfer mode can reduce downtime while increasing migration and rollback risk.

Do not delete the old cluster immediately

Retain what your tested rollback and data-retention plan requires, while ensuring it cannot accidentally receive production writes.

FAQs

When does PostgreSQL 14 reach end of life?

PostgreSQL 14's final community release is scheduled for November 12, 2026. After that, PostgreSQL 14 becomes unsupported by the PostgreSQL community and stops receiving new community security and bug fixes.

What is the latest PostgreSQL 14 version in August 2026?

The current minor release is PostgreSQL 14.24, released on August 13, 2026 as part of an update that fixed 28 security vulnerabilities and more than 110 bugs across supported PostgreSQL branches.

Can I upgrade directly from PostgreSQL 14 to PostgreSQL 18?

Yes, PostgreSQL 18's __INLINE_CODE_0__ supports upgrading from older supported cluster formats including PostgreSQL 14. The real constraints are extensions, binary/environment compatibility, application behaviour and your chosen infrastructure/provider procedure.

Should I upgrade PostgreSQL 14 to 17 or 18?

Both are supported targets in 2026. PostgreSQL 18 has the longer current community support window, while PostgreSQL 17 may be preferable where a critical extension or platform has better-established support. Choose after compatibility testing rather than from the version number alone.

Does a PostgreSQL major upgrade require downtime?

Most straightforward __INLINE_CODE_0__ and dump/restore cutovers require a maintenance window. Replication-based architectures can reduce downtime but add operational complexity. The correct method depends on database size, write volume and business availability requirements.

Will PostgreSQL 14 stop working after November 12?

No. Existing installations can continue running. The problem is that PostgreSQL 14 will no longer receive normal fixes from the PostgreSQL community, including future security fixes, which increases production risk over time.

Conclusion

PostgreSQL 14 end of life is not a reason for a panic migration. It is a reason to stop postponing a migration with a fully known deadline.

The right sequence in August 2026 is:

Patch 14 to the current minor release
        ↓
Inventory extensions and dependencies
        ↓
Choose a supported target
        ↓
Rehearse the real upgrade
        ↓
Test application compatibility and query performance
        ↓
Define rollback and validation
        ↓
Cut over before November 12

The largest risk is usually not the __INLINE_CODE_0__ command itself.

It is an untested extension, forgotten replica, stale connection pool, changed query plan, undocumented reporting integration or rollback plan that has never been executed.

Treat the migration as a software-system change rather than a database-version checkbox, and the deadline becomes manageable.

If your application needs a database upgrade alongside backend, deployment or application compatibility work, Softotic's custom software development service can support the migration architecture and application changes, while web application development can cover the application and production integration layer.

Sources and references

• PostgreSQL: Versioning Policy
• PostgreSQL: PostgreSQL 18.6, 17.11, 16.15, 15.19, 14.24 and 19 Beta 3 Released
• PostgreSQL 18 Documentation: Upgrading a PostgreSQL Cluster
• PostgreSQL 18 Documentation: pg_upgrade
• PostgreSQL 18 Release Notes
• PostgreSQL Security: CVE-2026-6471