PostgreSQL 18.4 Release Notes: Upgrade Checklist and Rollback Plan

Easy upgrade. Patch it like you mean it, because 18.4 includes 11 security fixes and a pile of correctness work.

Breaking changes and gotchas (read this first)

I have watched teams treat a “minor” Postgres update as a checkbox, then spend Saturday morning chasing a replica that will not follow WAL. Do not do that. Read the risk items, then run the checklist.

• Security fixes exist, even if your app “didn’t change”: The official announcement for 18.4 (and 17.10, 16.14, 15.18, 14.23) lists 11 CVEs. If your database accepts connections from anything you do not fully control, do not park this upgrade for a quarter.
• Tooling matters: If you use pg_basebackup or pg_rewind, read the security notes. If you run logical replication or publication refresh workflows, read the SQL-injection fixes in the announcement.
• Timezone data changed: 18.4 updates tzdata (the release notes call out tzdata 2026b). If you schedule jobs around local time, test your time-zone edge cases, especially around DST boundaries and region-specific rules.
• “No known issues” is not a guarantee: The release notes do not list known issues as of the release date. Your environment can still find one. Your extensions and your HA layer decide that.

If you’re running managed Postgres (RDS, Cloud SQL, Azure Database), skip to the migration steps section. Your provider controls the binaries and the rollback shape depends on snapshots.

Migration steps (methodical checklist)

Print this. Then follow it.

1) Pick the right target version

Upgrade within your major line. Go to 18.4 from 18.x, 17.10 from 17.x, and so on, per the official announcement.

• Supported versions updated together: 18.4, 17.10, 16.14, 15.18, 14.23 ship as the coordinated patch set. Verify your current major with SHOW server_version; before you schedule anything.

2) Capture a pre-upgrade baseline

This depends on your setup, but you need a “before” snapshot or you will argue with yourself later.

• Record version and settings: Run SHOW server_version; and save SHOW all; output somewhere that survives the maintenance window.
• Record query hot spots: If you run pg_stat_statements, take a snapshot of top queries (p95 latency, calls, total time). If you do not, at least save 5 slow queries and their EXPLAIN (ANALYZE, BUFFERS) output.

3) Back up like you plan to restore

Take a backup you can restore to a clean machine. Test the restore. Yes, even for a patch release.

• Physical snapshot: If you use volume snapshots, take one for the data volume and one for config. Coordinate it with your filesystem and your Postgres shutdown policy.
• Logical fallback: Keep a recent pg_dump or pg_dumpall for “I need the data back” scenarios, even if you prefer physical restores.

4) Upgrade in staging first

This bit me once with an extension package mismatch. The database came up, the app came up, then one report query started throwing errors because the extension binary lagged the server minor.

• Inventory extensions: List installed extensions and versions before you upgrade. If you run PostGIS or other third-party modules, confirm the repository provides matching packages for your distro and Postgres major.
• HA rehearsal: If you run primary/standby, practice the order. Upgrade standby first in most setups, then fail over, then upgrade the old primary. Do not improvise during the window.

5) Perform the production upgrade

Use your normal mechanism. Keep the steps boring.

• Package-managed installs: Upgrade the Postgres packages from your vendor or PGDG repository, then restart the service. Confirm the postmaster binary and the reported server version match 18.4.
• Containers: Pin the new image tag explicitly. Restart the pod, then confirm the running container actually pulled the new tag, not a cached layer.
• Managed services: Schedule the provider minor version update, then plan for a brief reconnect storm. Most apps do not handle that as well as they claim.

What’s new in 18.4 (the operator version)

Do not expect shiny features. Expect fewer sharp edges.

• Security fixes (11 CVEs): The official announcement lists the CVE set fixed across supported versions. Read it and map it to your exposure, especially for client connections, logical replication commands, and backup tooling.
• Planner and behavior fixes: The 18.4 release notes include planner changes and correctness fixes that can alter plans in specific cases. That can help performance. It can also surprise you if you rely on a specific plan shape.
• Timezone data update: tzdata updates can change the answer to “what time is it” for a subset of regions. That sounds small until your billing cutoff shifts by an hour.

Ignore the GitHub commit count. It’s a vanity metric. Read the CVEs and the replication and backup tool fixes instead.

What to test after the upgrade

Test the boring paths first. Then test the one weird thing your business depends on.

• Version and health: Confirm SHOW server_version; reports 18.4. Check logs for startup warnings, extension load errors, and auth failures.
• Connection and auth: Test your app’s login path, your pooler (if you run one), and your client drivers. If you still have MD5 password hashes from ancient upgrades, review the security note about timing behavior.
• Replication: Verify replication lag, WAL replay, and failover behavior. If you run logical replication, test subscription refresh and apply workers with a small canary table.
• Backups and restores: Run one full backup cycle and validate it. Do not wait until the next incident to discover your backup tool broke after the patch.
• Performance smoke test: Re-run your baseline queries. Compare p95 latency and buffer reads. If a plan regresses, capture the new plan and decide whether you need updated stats, a query tweak, or a targeted index change.

Other stuff in this release: planner tweaks, backup tooling fixes, timezone data, the usual.

Rollback plan (if this breaks)

Plan the rollback before you start. You will not think clearly when the pager rings.

• Fast rollback (best case): If you took a storage snapshot and you did not run an irreversible data migration, stop Postgres and restore the snapshot. Bring the service back up on the previous binaries.
• HA rollback: If you upgraded a standby first, keep one node on the old minor until you gain confidence. If the new primary misbehaves, fail back to the preserved node if your version-skew rules allow it.
• Last-resort restore: Restore from your last known-good backup to a fresh instance, then point the app at it. This costs time. It saves data.

I have not tested every combination of extensions with 18.4 in the wild, so treat your staging run as the truth. Anyway.

Official sources: read the announcement and the full 18.4 release notes before you schedule the window.

• Announcement (18.4, 17.10, 16.14, 15.18, 14.23): https://www.postgresql.org/about/news/postgresql-184-1710-1614-1518-and-1423-released-3297/
• Release notes (18.4): https://www.postgresql.org/docs/release/18.4/