Support Models
PostgreSQL Upgrade Guide: Planning the Move to 18 or 19
A PostgreSQL upgrade to a new major version means pg_upgrade, a dump and restore, or logical replication. Here are the supported versions and dates, the PostgreSQL 18 pitfalls and how senior DBAs run the upgrade safely.
Need a hand with this? Talk to a senior database DBA ↓By RadixTrie10 November 20265 min read
A PostgreSQL upgrade to a new major version (say 14 to 18) needs pg_upgrade, a dump and restore, or logical replication. A minor update (say 14.23 to 14.24) only needs new binaries and a restart. As of 8 November 2026, PostgreSQL 14 to 18 are supported, PostgreSQL 14's final release is due on 12 November 2026 (it is end of life after that), and PostgreSQL 19 is planned for general availability on 19 November 2026.
RadixTrie's PostgreSQL DBA services cover the whole job. We assess your estate, rehearse the upgrade, run the cutover and look after the database afterwards. Below is how our senior DBAs approach it, and what to watch for.
PostgreSQL versions and end-of-life dates
The PostgreSQL Global Development Group supports each major version for five years after its first release. It then ships one final minor release, and the version is unsupported. Supported versions get a minor release with bug and security fixes at least every three months. The dates below are from the PostgreSQL versioning policy.
- PostgreSQL 19: release candidate since 15 October 2026; general availability planned for 19 November 2026.
- PostgreSQL 18: released 25 September 2025; supported until 14 November 2030.
- PostgreSQL 17: released 26 September 2024; supported until 8 November 2029.
- PostgreSQL 16: released 14 September 2023; supported until 9 November 2028.
- PostgreSQL 15: released 13 October 2022; supported until 11 November 2027.
- PostgreSQL 14: released 30 September 2021; final release 12 November 2026.
- PostgreSQL 13: end of life since 13 November 2025.
- PostgreSQL 12: end of life since 21 November 2024.
If you run 13 or older, you are already without security fixes. If you run 14, our PostgreSQL 14 end-of-life guide covers the dates and the managed-service options in detail. This page is about doing the upgrade itself.
Minor update or major PostgreSQL upgrade?
A minor release keeps the same on-disk format. You stop the server, install the new binaries and start it again. Read the release notes first, because some minor releases ask for extra steps such as rebuilding certain indexes.
A major release can change the internal storage format. The data has to be carried across with one of three methods. The official upgrading guide describes all three. Choosing between them is mostly a question of downtime, disk space and how you will roll back.
Three ways to upgrade PostgreSQL
pg_upgrade: in place and fast
pg_upgrade moves your data files to a new major version without a dump and restore. Its transfer mode matters more than anything else on the day:
- Copy (the default) leaves the old cluster usable but needs room for two copies of the data.
- Link uses hard links. It is much faster and uses little extra disk, but both data directories must sit on the same file system. Once the new cluster starts, the old one cannot be used.
- Clone gives link-mode speed while keeping the old cluster intact, where the file system supports it.
- Swap, new in PostgreSQL 18, moves the data directories into the new cluster. The old cluster may be destructively modified. (There is also a copy-file-range mode, a faster copy where the operating system supports it.)
Always run pg_upgrade --check first, with the same mode flag you will use for real. It changes nothing, can run while the old server is up, and lists the manual fixes you need.
Dump and restore
Dump with pg_dumpall and restore into the new version. The documentation recommends using the dump tools from the newer version. It is simple and predictable, but every table and index is rebuilt, so the outage grows with the size of the database. It suits small databases and estates moving to new hardware anyway.
Logical replication
Build a new server on the new version and replicate into it. This works because logical replication supports replication between different major versions. When it has caught up, you switch the application over. Downtime is the shortest of the three, but there are more moving parts. Schema changes are not replicated, and before PostgreSQL 19 sequence values are not either, so both need a plan.
What changed for upgrades in PostgreSQL 18 and 19
- Data checksums are on by default. In PostgreSQL 18, initdb enables data checksums. pg_upgrade needs the old and new clusters to match, and most older clusters were built without checksums. Either run initdb with --no-data-checksums, or enable checksums on the old cluster with pg_checksums while it is shut down.
- Planner statistics survive. pg_upgrade now keeps optimiser statistics, so queries no longer start with no statistics after the upgrade. Extended statistics created with CREATE STATISTICS, and statistics added by extensions, are not carried across. Afterwards run vacuumdb --all --analyze-in-stages --missing-stats-only, then vacuumdb --all --analyze-only.
- A new swap mode joins copy, link and clone (see above).
- PostgreSQL 19 helps online upgrades. Due with the 19 November release (the release notes are still a draft), logical replication replicates sequence values and can be enabled without a server restart when wal_level is set to replica.
- Read the migration notes. The draft PostgreSQL 19 notes, for example, double the default max_locks_per_transaction from 64 to 128 and change how the setting is sized. Small changes like this break scripts and tuned configurations.
Full details are in the PostgreSQL 18 release notes and the PostgreSQL 19 RC 1 announcement.
Which version should you upgrade to?
If you must go live this year, target PostgreSQL 18. It has been in production use for over a year and is supported until November 2030. If your realistic go-live is 2027, test against the PostgreSQL 19 release candidate now and plan for 19 once it is generally available. You can upgrade straight from an old major to the new one. You do not need to step through each version, but you do need to read the migration notes for every version you skip.
Managed services follow their own calendars. The Amazon RDS release calendar keeps PostgreSQL 14 in standard support until 28 February 2027. After that, instances are automatically enrolled in paid Extended Support. Azure Database for PostgreSQL ends standard support for 14 on 31 January 2027 and moves servers still on 14 into paid Extended Support from 1 February 2027.
How we run a PostgreSQL upgrade
- Inventory. Versions, extensions, database sizes, object counts, replicas, HA tooling and client drivers. With link mode, run time tends to depend more on the number of tables and indexes than on gigabytes.
- Compatibility review. We read the migration notes for every major version you skip and check extensions are available for the target.
- Rehearsal. We run the full upgrade on a copy of production, using the real mode flags, and time it. The application team tests against the result.
- Rollback plan. A verified backup, plus a standby left on the old version when we use link or swap mode.
- Cutover. A final --check, the upgrade, extension updates and statistics, then smoke tests before users return.
- Afterwards. Rebuild standbys, compare query performance against the pre-upgrade baseline, and prove that backups and restores work on the new version.
Standbys and failover need their own plan during an upgrade. Our guide to high availability and disaster recovery explains the trade-offs.
PostgreSQL DBA services beyond the upgrade
An upgrade is a good moment to fix what has drifted. We often start with a database health check, then carry on with ongoing administration: monitoring, quarterly minor-release patching, backup and restore testing, replication and failover, and performance tuning. If you need help with a specific incident rather than ongoing care, see our PostgreSQL support service.
We work remotely from Randpark Ridge in Johannesburg and from Stellenbosch, for clients in South Africa and internationally. Alongside PostgreSQL, the same team looks after SQL Server and Oracle, so mixed estates get one point of contact.
Frequently asked questions
How do I upgrade PostgreSQL to a new major version?
Use pg_upgrade for a fast in-place upgrade, pg_dumpall and restore for small databases, or logical replication to a new server when downtime must be minimal. Run pg_upgrade --check with your chosen mode first.
Does a PostgreSQL upgrade need downtime?
Major upgrades with pg_upgrade need an outage. In link mode it is usually short, and it tends to depend more on the number of tables and indexes than on data size. Logical replication cuts downtime to a switchover. Minor updates need only a restart.
Can I upgrade from PostgreSQL 13 or 14 straight to 18?
Yes. pg_upgrade and dump and restore go directly between major versions. Read the migration notes for every version you skip, and on PostgreSQL 18 match the data checksum setting of the old cluster.
When is PostgreSQL 14 end of life?
12 November 2026, when its final minor release ships. After that it gets no more security or bug fixes from the community.
What is the difference between a minor and a major PostgreSQL upgrade?
A minor upgrade (14.23 to 14.24) keeps the storage format: install the new binaries and restart. A major upgrade (14 to 18) can change the format, so data is moved with pg_upgrade, dump and restore, or logical replication.
Need a hand with this?
Tell us what you run today and when it has to move. A senior database DBA will reply directly, usually within one working day. Prefer email or phone? Write to expert@radixtrie.com or call +27 10 143 0304, or use the contact page to book a 30-minute call. We provide DBA services in the United Kingdom, United States, Canada and Australia, as well as South Africa.
TAGSPostgreSQLPostgreSQL upgradepg_upgradeEnd of lifeManaged DBA servicesHigh availability