PostgreSQL 18.6 is out, and 18.5 never shipped

PostgreSQL 18.6 arrived on August 13, 2026, and there was no 18.5. The 18.5 build was never released, because a regression was discovered after the release was wrapped. The result is a double-sized patch: the release announcement records 28 security fixes and over 110 bug fixes across the supported branches.

A missing version number is easy to read as a non-event. It is the opposite. Everything intended for 18.5 is in this release, so the usual "we skip a point release now and then" habit skips two.

What is in PostgreSQL 18.6?

PostgreSQL 18.6 is a cumulative bug-fix and security release for the PostgreSQL 18 branch. PostgreSQL is the open-source relational database used across most Western SaaS and analytics stacks, and its minor releases contain only fixes, never new features or catalog changes.

The headline items in the 18.6 release notes fall into four groups:

Area	What changed	Who is affected
Security	28 fixes, including injection and overflow issues	Anyone exposing SQL surfaces to user input
Correctness	Crash, data integrity and privilege fixes	All installations
Replication	Logical decoding and replication fixes	Clusters with replicas or subscribers
Platform	OpenSSL 4 support, tzdata 2026c	Distributions that moved to OpenSSL 4

The OpenSSL 4 item deserves a note of its own, because it is the one that turns a routine patch into a blocker. OpenSSL is the cryptography library PostgreSQL uses for TLS connections. Distributions that have shipped OpenSSL 4 need a PostgreSQL build that knows about it, and 18.6 is the first release in this branch that does.

Which fixes can application code actually reach?

Three of them, and they are the reason to prioritize this patch over a normal minor release.

The first is ltree. ltree is a contrib extension that stores label paths, such as a category tree or an org chart. It queries them with the lquery type. Values with more than 64K items caused internal overflows. The fix guards against overly long lquery values, as the current release notes index shows for each supported branch. If your app builds an lquery from user input, that path is reachable.

The second is contrib/spi, where the release prevents SQL injection and buffer overruns. The third is pg_createsubscriber, which now properly quotes subscription names to prevent SQL injection. That last one matters to anyone scripting logical replication setup with names drawn from a tenant list or a config file.

Consider the difference between those and the rest of the list. A planner fix changes performance. An injection fix in a code path fed by user data changes your exposure, and it does so whether or not you ever noticed the bug.

Does a managed database patch this for me?

Managed providers patch on their own schedule. The answer is yes eventually, and rarely today. Amazon RDS, Google Cloud SQL and Azure Database for PostgreSQL each stage minor versions through their own release trains. Each also sets its own maintenance windows. The project's version support policy sets the upstream dates, not the provider's calendar.

Self-hosted installs are the exposed group. A Postgres pinned to 18.4 in a container image still carries the injection fixes unpatched. So does one from a distribution package that has not been rebuilt. That includes dev databases on the same network as production. It also includes analytics replicas that nobody counts as production.

The check takes one query:

SELECT version();

Anything reporting 18.4 or lower on the 18 branch is missing both the withdrawn 18.5 fixes and the 18.6 fixes. The same applies on the older branches, where the current releases are 17.11, 16.15, 15.19 and 14.24.

How to apply PostgreSQL 18.6 safely

1. Record the current version with SELECT version(); on every instance, including replicas and non-production copies.
2. Read the earlier 18.4 release notes if you are more than one release behind, because you inherit those fixes too.
3. Patch replicas first, then promote or fail over, then patch the primary.
4. Restart the service after installing the new binaries, since a minor upgrade needs no dump, restore or pg_upgrade run.
5. Verify TLS connections explicitly if your distribution has moved to OpenSSL 4, because that combination is new in this release.
6. Re-run SELECT version(); afterwards, since a package upgrade that never restarted the service is the most common false completion.

Minor PostgreSQL upgrades do not change the on-disk format. That is why this is a restart, not a migration. It is also why deferring them is hard to justify. The risk is one service restart. The alternative is running known-vulnerable code.

Should you patch now or wait for the next release?

Patch now if you self-host, and especially if you use ltree, contrib/spi, or scripted logical replication. Those three fixes are the reachable ones, and PostgreSQL 19 is still in beta, so there is no imminent release to wait for.

Wait only if your managed provider has not staged the minor version yet. Even then, check the provider's version page and set a reminder. Doing nothing is not the same as waiting.

The reasoning here is the same one applied in SCTPhantom gives root on Linux. Do you need to care? — the question is never how alarming the advisory sounds, but whether the vulnerable code path is one your system actually reaches. Readers weighing a similar runtime decision will find the same trade-off in Node.js 26 turns Temporal on. Upgrade now or wait?