PostgreSQL Minor Version Upgrade: Patching Steps for Linux, Windows, Containers, RDS and Aurora

The short answer

A PostgreSQL minor version upgrade replaces the binaries and keeps the data directory. Stop the server, install the new packages for the same major version, start it again. There is no dump and restore and no pg_upgrade, because minor releases never change the on-disk format. The PostgreSQL project's advice is to always run the current minor release of your major version, and to read the release notes first, because some releases ask for an extra step afterwards, such as rebuilding certain indexes.

The current minor releases are 18.6, 17.11, 16.15, 15.19 and 14.24. The next scheduled release date is 12 November 2026, which is also the final release for PostgreSQL 14.

What a minor release contains, and why to apply it promptly

The project's versioning policy says minor releases contain only fixes for frequently encountered bugs, low-risk fixes, security issues and data corruption problems, and that it considers upgrading less risky than staying on an old minor version. They ship at least once a quarter, on the second Thursday of February, May, August and November, with extra releases when a fix cannot wait. The scheduled dates ahead are 12 November 2026, 11 February 2027, 13 May 2027 and 12 August 2027.

Security fixes are the obvious reason to keep up, but the data-corruption fixes matter as much. A bug that silently damages an index does its harm whether or not anyone has written an exploit for it.

Read the release notes: the "Migration to Version" section

Every minor release note opens with a short section headed "Migration to Version X.Y". Usually it says only that a dump and restore is not required. Sometimes it asks for more, and those are the steps that get missed. Recent examples, from the PostgreSQL release notes:

The notes also chain together: 18.6 says that anyone upgrading from earlier than 18.2 must also follow the 18.2 instructions. If you skip several minor releases, read every one in between.

Before you patch

-- Current version
SELECT version();
SHOW server_version_num;

-- Extensions installed in this database (repeat per database)
SELECT extname, extversion FROM pg_extension ORDER BY extname;

-- Is this server a standby?
SELECT pg_is_in_recovery();

• List every minor release between the version you run and the target, and collect their "Migration to Version" steps.
• Take a backup you have tested, or confirm the last base backup and WAL archive are good.
• Note which extensions come from separate packages, such as PostGIS or pgvector. Their packages update on their own schedule and need ALTER EXTENSION ... UPDATE when they change.
• Plan the order across a replicated cluster: standbys first, then a switchover, then the former primary.

Linux: Debian and Ubuntu with the PGDG APT repository

The PostgreSQL Apt repository packages each major version separately, as postgresql-18, postgresql-17 and so on, so an update stays within the major version you run:

sudo apt-get update
apt-cache policy postgresql-18          # confirm the candidate version

sudo apt-get install --only-upgrade postgresql-18 postgresql-client-18
sudo systemctl restart postgresql@18-main   # cluster name as shown by pg_lsclusters
sudo -u postgres psql -c "SELECT version();"

Run this inside your maintenance window, because the server has to restart to load the new binaries. Include any extension packages for the same major version, such as postgresql-18-pgvector, in the same change.

Linux: RHEL, Rocky and AlmaLinux with the PGDG Yum repository

The PostgreSQL Yum repository names packages postgresql18, postgresql18-server and so on, installs under /usr/pgsql-18, and runs the service as postgresql-18:

sudo dnf check-update 'postgresql18*'
sudo systemctl stop postgresql-18
sudo dnf upgrade 'postgresql18*'
sudo systemctl start postgresql-18
sudo -u postgres psql -c "SELECT version();"

If you use the distribution's own PostgreSQL module instead of PGDG, the distribution decides when minor releases arrive. Check its errata rather than postgresql.org for the timing.

Windows: the EDB installer

On Windows, postgresql.org points to the interactive installer by EDB, which EDB tests on 64-bit Windows 2025 and 2022 platforms for PostgreSQL 18. The installer treats every minor version of a major version as an update to the same installation directory and registry keys; only different major versions install side by side. To patch:

1. Stop applications or put them in maintenance, and take a backup.
2. Download the installer for the new minor release of the same major version and run it. It updates the binaries of the existing installation; the data directory stays where it is.
3. Make sure the PostgreSQL Windows service is running again, then confirm with SELECT version();.
4. Apply any steps from the release notes.

For scripted estates, the installer also runs in silent mode, and EDB publishes a zip archive of the binaries for teams that manage files and services themselves.

Containers and Kubernetes

With the official postgres image, pin the exact minor tag, such as postgres:18.6, rather than a floating postgres:18, so the version changes only when you choose. A minor upgrade is a new tag on the same volume:

# docker compose: change the image tag, then
docker compose pull db
docker compose up -d db
docker compose exec db psql -U postgres -c "SELECT version();"

On Kubernetes, the operator usually handles this. CloudNativePG, for example, performs rolling updates for PostgreSQL minor versions when you change the image in the Cluster resource. See our PostgreSQL operator comparison for how each operator approaches it.

Amazon RDS for PostgreSQL

RDS offers two routes:

• Auto minor version upgrade. With the option enabled, RDS upgrades the instance during your maintenance window once a minor version has been tested and designated as the automatic upgrade target for your major version. RDS does not automatically make each new community minor release the target.
• Manual upgrade with the console or CLI, immediately or in the next window:

# Find the valid targets for your current version
aws rds describe-db-engine-versions --engine postgres --engine-version 17.10 \
  --query "DBEngineVersions[*].ValidUpgradeTarget[*].{AutoUpgrade:AutoUpgrade,EngineVersion:EngineVersion}" \
  --output table

# Upgrade in the next maintenance window
aws rds modify-db-instance --db-instance-identifier mydb \
  --engine-version 17.11 --no-apply-immediately

Expect downtime. A Multi-AZ DB instance upgrades the primary and standby at the same time and can be unavailable for several minutes. A Multi-AZ DB cluster upgrades readers one at a time and then fails over, which AWS says typically reduces downtime to about 35 seconds. Read replicas must be upgraded before their source. RDS also does not upgrade extensions during the engine upgrade, so run ALTER EXTENSION ... UPDATE afterwards where a newer extension version is available.

Amazon Aurora PostgreSQL

Aurora applies minor upgrades through the same auto minor version upgrade setting, which should be enabled on every instance in the cluster, or by applying pending maintenance from the console. Aurora PostgreSQL adds zero-downtime patching: the engine waits for a quiet point, pauses new transactions, and keeps most client sessions through the restart. AWS says the throughput drop typically lasts a few seconds and at most about a minute. It does not always succeed; pending parameter changes, for example, can prevent it. Applications should still retry failed transactions.

Rolling back a minor upgrade

Because minor releases never change the storage format, a self-managed server can usually go back by reinstalling the previous minor packages and restarting. Two caveats. First, any repair you made after upgrading, such as a reindex, stays done, and downgrading reintroduces the bugs that release fixed. Second, a standby on a newer minor can replay WAL from an older primary, but the 18.3 notes describe a replay failure in exactly that mixed-version setup, which is another reason to finish the upgrade promptly rather than leave versions mixed.

On RDS there is no downgrade: AWS states that you cannot revert after an upgrade. If backup retention is above zero, RDS takes a snapshot before the upgrade, and restoring it creates a new instance on the old version.

When there are no more minor releases

Minor releases stop when a major version reaches end of life. For PostgreSQL 14 the final one is due on 12 November 2026; 13 ended in November 2025. From then on, patching means a major upgrade, which our major version upgrade guide covers, or a source of patched builds for the version you run.

Where OSSeva fits

OSSeva for PostgreSQL keeps minor patching going after community end of life. OSSeva ships patched, signed builds for 11, 12 and 13 today and for 14 after 12 November 2026, as quarterly releases aligned with the community schedule. Each build stays on the same major version, so installing it is the same procedure as above: stop, replace the binaries, start on the same data directory, replicas first. Every build is signed, and our post on verifying signed database packages shows how to check one before it goes near production. For how quickly fixes reach each version, see open source database CVE response times. OSSeva Operate adds 24/7 replication and failover monitoring and a 15-minute P1 response. PostgreSQL sits under one contract with MySQL, MariaDB, Redis, Valkey and Kafka, priced per cluster. Book a discovery call for a quote.

Frequently asked questions

Does a PostgreSQL minor upgrade need pg_upgrade or a dump and restore?

No. Minor releases keep the same storage format, so you stop the server, replace the binaries and start it again on the same data directory.

How often does PostgreSQL release minor versions?

At least once a quarter, on the second Thursday of February, May, August and November, with extra releases for urgent fixes.

Do I need to restart PostgreSQL for a minor upgrade?

Yes. The new binaries load only when the server restarts. In a replicated cluster, restart standbys first and switch over to keep downtime short.

How do I upgrade a PostgreSQL minor version on Windows?

Run the EDB installer for the newer minor release of the same major version. It installs into the existing directory as an update, and the data directory is unchanged.

How does RDS handle PostgreSQL minor version upgrades?

Either automatically, during your maintenance window, once RDS designates a version as the automatic upgrade target, or manually with modify-db-instance. Upgrade read replicas first, and update extensions yourself afterwards.

Can I downgrade a PostgreSQL minor version?

On a self-managed server, usually yes, by reinstalling the previous packages, because the storage format is the same. Any post-upgrade repairs stay in place. On RDS, you restore the pre-upgrade snapshot to a new instance instead.