PostgreSQL 14 reaches end of community support on 12 November 2026. Plan a migration to a supported major version, rehearse it against a restored copy, and reserve a maintenance window that includes validation and recovery. Installing the last PostgreSQL 14 patch does not extend its support lifecycle. The date comes from the PostgreSQL versioning policy.
The practical question is how to move your application and its data together. A small database with an acceptable maintenance window often needs only a carefully rehearsed dump and restore. A large installation with a narrow interruption budget may need logical replication or a provider-operated upgrade. None of these choices guarantees zero downtime.
Choose a target with enough support runway
As of 1 November 2026, PostgreSQL 15 through 18 are supported upgrade candidates. Choose the newest major version that your application, extensions, drivers and hosting service support together. Moving from 14 to 15 may solve an immediate compatibility constraint, but creates another upgrade deadline sooner than moving to 17 or 18.
| Target | Scheduled final community release | Planning implication |
|---|---|---|
| PostgreSQL 15 | 11 November 2027 | Shorter runway; justify compatibility constraints. |
| PostgreSQL 16 | 9 November 2028 | Check your application's supported matrix. |
| PostgreSQL 17 | 8 November 2029 | Validate extensions before selecting it. |
| PostgreSQL 18 | 14 November 2030 | Longest runway among these candidates. |
These are community dates, not a promise about any provider's extended support. Confirm any commercial arrangement separately. PostgreSQL permits skipping intermediate major versions; nevertheless, read the migration notes for every version crossed, as the major-upgrade documentation recommends.
Inventory what must survive the upgrade
Start with read-only discovery on each application database. Record the output alongside the intended target, the application release and the person approving the cutover:
SHOW server_version;
SELECT current_database(), current_user;
SELECT extname, extversion FROM pg_extension ORDER BY extname;
SELECT pg_size_pretty(pg_database_size(current_database()));
SELECT datname, pg_encoding_to_char(encoding), datcollate, datctype
FROM pg_database
WHERE datname = current_database();Check every database, not just the one used by the public website. A reporting job, background worker, integration script or old administration tool can be the only remaining client using an incompatible driver. Identify scheduled jobs, connection pools, replication consumers, foreign data wrappers and authentication settings. Write down which of them can write data.
Make compatibility a short evidence list: the application vendor supports the target; extension packages exist for it; a restored database loads successfully; and the application's important operations pass. If a geographic extension or custom C module is involved, confirm its own upgrade procedure rather than treating the database engine version as the whole decision.
Set acceptance criteria before testing. For an order-processing application, useful checks include creating and updating a draft order, checking a recent paid order, running a background job and producing the daily report. Define which totals must agree. A successful database connection is necessary, but says little about whether the business process still works.
Choose a method your access actually supports
| Method | Useful when | Main constraint |
|---|---|---|
| Dump and restore | You can provision a separate destination and allow an interruption. | The final export, transfer, restore and checks must fit the window. |
| pg_upgrade | You administer compatible server installations and their data directories. | Requires filesystem and binary access; usually not available through a managed database connection. |
| Logical replication | Data is large and writes must continue during most of the copy. | Requires replication privileges, monitoring and a carefully controlled final switchover. |
Where pg_upgrade fits
pg_upgrade works with the old and new server binaries and cluster directories. Its --check mode checks prerequisites without performing the upgrade. It does not validate all application behavior or prove that external modules are compatible.
Do not point pg_upgrade at two remote connection strings. For a managed service, ask whether the provider offers an engine upgrade and what its backup, interruption and recovery procedure covers. Otherwise, use a new instance and a supported data-transfer method. Avoid treating link mode as a casual speed optimization: after starting the upgraded cluster, the old linked cluster is not an independent rollback copy.
Where logical replication adds work
Logical replication can copy data while the source remains active, but its documented restrictions matter: schema changes and sequence state are not replicated, and PostgreSQL large objects are not replicated. Audit those features before selecting this route. Check replica identities for tables receiving updates or deletes.
A useful plan includes a schema-change freeze, initial copy, lag monitoring, a final write pause, sequence synchronization and application reconnection. Also monitor replication-slot disk retention. A subscriber that falls behind can create an operational problem on the source. Use this method when the reduced copy-time interruption is worth the additional moving parts.
Rehearse dump and restore on an empty destination
The following example migrates one trusted application database. It assumes you already created an empty destination with the required locale and encoding, installed compatible extension packages, and provisioned the required roles. Use client tools from the chosen target major version; pg_dump supports exporting older servers. A custom-format archive is convenient because it supports parallel restoration.
Because this example restores into an existing empty database without --create, explicitly recreate its owner, database-level grants and revocations, per-database settings, and ALTER ROLE ... IN DATABASE settings from your inventory. These are separate from table ownership and grants. Test connections and permissions with the actual application roles. The pg_restore reference associates database-level metadata restoration with --create; adding that flag would instead restore into the database name recorded in the archive.
Define pg14-source and pg-target-rehearsal in your local connection service file, with explicit host, database, user and TLS settings. Keep passwords in a password file protected with mode 0600 on Unix, or your approved secret mechanism. Do not paste password-bearing URLs into shell history.
umask 077
pg_dump --dbname='service=pg14-source' \
--format=custom --file=app-rehearsal.dump
pg_restore --list app-rehearsal.dump > app-rehearsal.contents
pg_restore --dbname='service=pg-target-rehearsal' \
--exit-on-error --jobs=4 app-rehearsal.dump
vacuumdb --dbname='service=pg-target-rehearsal' --analyze-onlyFour restore jobs are an illustrative starting point, not a measured recommendation for your server. Match concurrency to available CPU, I/O and connection capacity. Inspect warnings and the exit status at every step. Listing an archive checks that its catalogue can be read; only restoring it and validating the result demonstrates recoverability.
pg_restore continues after errors by default, which is why this example uses --exit-on-error. Do not run it against an existing production database or add --clean to make errors disappear. For another rehearsal, provision another empty database through your normal process.
A single-database dump excludes cluster-wide roles and tablespaces. Where permitted, capture globals separately with pg_dumpall --globals-only, review the result and adapt it to the destination's administrative model. Managed services often restrict superuser roles or tablespaces. The SQL backup guide explains this separation. Treat global exports as sensitive because role definitions can include password hashes.
Preserve and review ownership and grants. Adding --no-owner or --no-acl changes the resulting security model; it is not a universal managed-hosting fix. An application with privileged functions, reporting roles or row-level security needs explicit permission testing after any role mapping.
Measure your own export, transfer, restore, statistics collection and application checks separately. Save those durations and the database size. The sum, plus a deliberate contingency allowance, is a more useful maintenance estimate than a generic claim about minutes per gigabyte.
Cut over with a single authoritative writer
- Prepare the destination. Repeat the rehearsed configuration and confirm storage headroom, credentials, network access and backups.
- Pause every source writer. Include workers, scheduled commands, imports and third-party integrations. Let in-flight work finish according to your application procedure.
- Take the final consistent export. A live dump is consistent, but later writes are absent. Keep writers paused until the migration decision is complete.
- Restore and validate. Check restore errors, extensions, grants and business-level totals before changing application connections.
- Reconnect clients deliberately. Update secrets or connection settings and recycle long-lived workers and pools. A DNS change alone may leave established connections on the old server.
- Resume with controlled checks. Confirm a real write, background processing and a read of that new data. Keep the old source protected from new writes.
After a restore, collect planner statistics and investigate changed query behavior using the ANALYZE documentation. Observe connection errors, lock waits, resource pressure and slow application requests. PostgreSQL's statistics views help distinguish connection or blocking problems from application failures. Use the same representative workload before and after; do not assume a newer engine makes every query faster.
For the next pass, our PostgreSQL performance guide and connection pooling guide cover related operational decisions.
Define recovery before accepting new writes
There are two distinct recovery situations. Before the destination accepts writes, you can usually abandon it and reconnect to the unchanged source, following your rehearsed procedure. After it accepts writes, that old source is stale. Switching back without reconciliation can lose new orders, transactions or user changes.
Write down the decision point, who can invoke recovery, and how post-cutover writes would be recovered or reconciled. Retain the original source and protected backups for an agreed period. Do not delete them just because the homepage loads. Verify a fresh backup of the new installation and its restore path; see our PostgreSQL backup guide.
If you are evaluating a new destination, review DanubeData PostgreSQL hosting and discuss your required version, extensions, migration method and maintenance window before committing to a cutover.
Frequently asked questions
Will PostgreSQL 14 stop working on 12 November?
No. End of support ends community fixes for that major version; it does not impose a shutdown. Continuing to run it means accepting an unsupported engine unless you have a separate support arrangement.
Can I upgrade directly from 14 to 18?
PostgreSQL supports skipping intervening major versions. Your application, extensions and provider must also support the destination. A rehearsal and the intervening release notes remain essential.
Is a disk snapshot enough for a major upgrade?
It can be part of a same-version recovery plan, but a PostgreSQL 14 data directory is not a logical migration into PostgreSQL 18. Use a supported upgrade mechanism and retain an independently recoverable backup.
How much downtime should I book?
Use the rehearsed time for the final data transfer and validation, including application reconnection and a recovery allowance. Database size alone cannot predict it. Logical replication can shorten the transfer interruption but still needs a final controlled cutover.
Sources and further reading
- PostgreSQL release support dates
- Major-version upgrade methods
- pg_upgrade requirements and recovery caveats
- pg_dump reference and pg_restore reference
- Logical replication restrictions