On August 13, 2026, PostgreSQL shipped its biggest security release ever: 28 CVEs closed in a single day. The old record was 11.

The community has done its job, a phenomenal one at that! If you run PostgreSQL for critical workloads in production, the number you should focus on is how long it takes to get a fix from “released” to “running in production.” Call it your patch latency. That’s what this post is about.

The Count Went Up Because the Attention Went Up

Here is the trend in plain numbers. Postgres fixed 7 CVEs in all of 2025; 44 in 2026 so far, and 28 of those landed in one release.

The panic reading is that the code got worse. The real reading is that more people are looking, and better tools are doing the looking. Some of these bugs were reported by AI security teams, including OpenAI’s. And the bugs they’re finding – buffer overflows, integer wraparounds, type confusion – are classic memory-safety bugs. That’s exactly what automated fuzzing is good at catching, and AI is making fuzzing a lot better.

Browsers and operating system kernels got this level of attention years ago. Postgres is getting it now. Every bug that’s found and fixed is one an attacker can’t use on you later.

The gap between a fix being published and that fix being live on your servers is what you need to focus on.

Why the Gap Is the Risk

A CVE is a public document. It names the bug, lists the affected versions, and often gives away enough detail to build an exploit. One of the August bugs, a remote code execution flaw in to_char(), already has a working proof of concept posted publicly. A national cybersecurity center put out a “patch immediately” advisory for it.

The same AI that helps defenders find these bugs helps attackers turn them into working exploits. The time between “CVE published” and “someone is scanning your servers with it” keeps getting shorter.

We saw how this plays out in early 2025. CVE-2025-1094, a SQL injection bug hiding in Postgres’s own string-escaping functions, showed up as part of a real-world attack chain, the kind used to breach live systems. The bug had been sitting in stable code for years. It only mattered once it was public and someone motivated picked it up.

Put in business terms: an unpatched, publicly disclosed CVE is a known door with the lock-picking instructions printed next to it.

The Good News: Applying a Minor Release Is Cheap

This is where Postgres makes your life easy.

Minor releases (18.4 to 18.6, 17.10 to 17.11, and so on) are cumulative and binary-compatible. No dump and reload. No pg_upgrade. You stop the server, swap the binaries, and start it back up. On a single node, that takes seconds.

So if the patch itself takes seconds, why do teams take weeks? Because the swap was never the expensive part. Testing is. Scheduling is. Doing it without dropping live connections is. A patch SLA turns all of that from a scramble into a routine.

What a Postgres patch SLA looks like

An SLA here is just a promise you make to yourself about how fast you move, sorted by how bad the bug is. Something like:

• Remote code execution, or a public exploit exists: patch within days. This month’s release is a clear example.
• High severity, no known exploit yet: patch within one to two weeks.
• Everything else: roll it into your next scheduled maintenance window.

The exact numbers are yours to pick. The whole point is to decide them before a CVE lands. When a release like August 13 shows up, you already know it’s a “within days” event, and nobody’s arguing about it in a chat thread while the clock runs.

How to Hit the Window Without Breaking Things

Three habits make a tight SLA safe to keep.

Patch a standby first. Apply the update to a replica, watch it behave, then fail over and patch the old primary. Done right, your users see a short blip instead of an outage. This is the same standby-first discipline we use for rolling upgrades on Patroni clusters.

Test in staging, and actually read the “Updating” section. Most releases are a clean binary swap. Some ask for a follow-up step, and this one did. If you use GIN indexes, check that their reltuples values still look sane. If you use btree_gist on float or bit columns, or ltree with very long paths, you may need to reindex. Two minutes of reading saves you a confusing afternoon.

Keep a restore you’ve actually tested. Patching and recovery lean on the same muscle. When your backups restore cleanly, and you know your real recovery time, patching stops feeling risky, because you always have a way back. If you haven’t run a restore drill recently, do that before your next patch, not after.

Don’t Forget the Parts That Aren’t the Server

The server binary is the obvious target. It isn’t the whole job.

Client libraries and extensions get CVEs too. November 2025 patched a bug in libpq (an integer wraparound, CVE-2025-12818) that lived in the client library, not the server. This August’s batch touched pgcrypto, pg_stat_statements, and PL/Perl. If you pin driver versions, run a connection pooler, or depend on contrib modules, those all count toward your patch latency too. A fully patched server talking to an old client library is only half the way there.

Staying on an Unsupported Version Is Patch Latency, Too

There’s one guaranteed way to make your patch latency infinite: run a version that no longer gets fixes.

PostgreSQL 14 gets its final round of fixes on November 12, 2026. All 28 August CVEs were patched in 14.24, so there’s still time to apply this round and plan the move to a supported major version. After that date, any new bug found in 14 stays open. Permanently.

Patching cadence and version currency are the same discipline wearing two hats.

What to do This Week

The short version:

• Apply 18.6, 17.11, 16.15, 15.19, or 14.24 to production this week.
• Patch a standby first, then fail over.
• Read the “Updating” notes before you start.
• Write down your severity tiers so the next CVE isn’t a debate.

If you’d rather have that routine handled for you, running around the clock and staged safely across your fleet, that’s the operational side of what we do at Stormatics. Talk to us about 24×7 PostgreSQL support.

FAQ

How often does PostgreSQL release security updates?

Roughly every quarter, in February, May, August, and November, with the occasional out-of-cycle release when a fix can’t wait. The August 13, 2026 release closed 28 CVEs, the most in the project’s history. The minor release roadmap always lists out the next 4 releases here: https://www.postgresql.org/developer/roadmap/. 

Do I need to dump and reload to apply a minor PostgreSQL update?

No. Minor updates (like 17.10 to 17.11) are cumulative and binary-compatible. You stop the server, swap the binaries, and start it again. No pg_upgrade, no export/import.

How fast should I patch a PostgreSQL CVE?

Tie it to severity. For a remote code execution bug or one with a public exploit, patch within days. For high-severity bugs with no known exploit, within one to two weeks. Everything else can wait for your next maintenance window. Decide these tiers in advance.

Does patching PostgreSQL require downtime?

On a single node, you get a short restart. With a standby and a planned failover, you can patch with near-zero downtime by updating the replica first and switching over.

Is PostgreSQL less secure now that it fixed 28 CVEs at once?

No, the opposite. The jump comes from more scrutiny, including AI-assisted security research, finding old bugs in long-stable code. The bugs were already there. Finding and fixing them makes Postgres safer. The one thing you can control is applying updates promptly.