Key takeaways
A routine OS patch can take Postgres offline even when Postgres itself was never touched. Here’s what rolling OS patching on a proper HA cluster changes:

• OS-level patches (kernel, glibc, container runtime, storage driver) can take Postgres down even though Postgres was never touched.
• The usual fix, a maintenance window, breaks down once the business runs 24/7 or compliance wants patches applied fast.
• In a properly built Patroni HA cluster, OS patching is rolling and one node at a time. Postgres binaries, config, and data never change.
• Process: patch and rejoin each replica first, switch over to an already-patched node, then patch the old primary last.
• Safety depends on connection routing that follows the leader, replication caught up before switchover, honest health checks and quorum, reproducible node images, and a switchover you’ve already tested.
• A switchover causes a brief pause, not an outage, but you need at least one replica. A single-node database still needs a maintenance window.

A database went offline for a security patch, and Postgres was never the thing being patched.

The team needed an OS update across the cluster. Kernel level, the kind that only takes effect after a reboot. So they did what most teams do the first time this comes up: booked a maintenance window, took the database down, patched, rebooted, and brought it back. A clean, planned database outage for something that had nothing to do with the database.

I understand why it happens. But it points to a gap in how many teams think about uptime, and it is worth walking through because the fix costs you nothing on patch night once the cluster is built for it.

The Database Doesn’t Stand on Its Own

Your database runs on an operating system. That OS runs on a kernel.In most modern setups, that means a container runtime, a storage layer, a network layer, and underneath it all, a hypervisor or physical host. Postgres sits at the top of that pile and takes it all on faith.

Each layer affects your uptime. And each one ships patches. The kernel gets a security fix that needs a reboot. glibc gets an update. The container runtime moves to a new version. The storage driver has a CVE. None of that is a Postgres problem, and all of it can take Postgres down if the only thing you have guarded against is the database process falling over.

That is the trap. Teams build high availability to survive a database crash, a node dying, a disk filling up. Then a routine glibc update lands, someone reboots the box, and the database goes with it. The outage gets filed under “planned maintenance,” everyone moves on, and nobody notices that the availability design never covered the ground the database was standing on.

Availability is a property of the whole stack, and you get to decide how much of that stack you can service without an outage.

Why the Maintenance Window Becomes the Default

The maintenance window is an easy habit to fall into because it works, sort of. You announce it, you take the hit, the patch goes on, life continues. To be fair to the teams that do it this way, almost everyone starts here, and for a long time it feels fine.

It stops feeling fine the moment the business runs around the clock. A payments platform does not have a quiet hour. A bank has an end-of-day batch that cannot slip. A SaaS product with customers in every time zone has no 2 a.m. that is 2 a.m. for everyone. Now every OS patch is a negotiation: which SLA do we bend, whose window do we borrow, how long can we be down before it counts against us?

And OS patches are not optional in a regulated environment. When a kernel CVE lands, security and compliance want it applied immediately, not whenever the next maintenance window opens. So you end up with two forces pulling against each other: patch fast to stay secure, and stay up to meet your SLA. The maintenance-window model makes you choose. A cluster built for rolling operations means you don’t have to.

Rolling OS Patching, One Node at a Time

Here is the part I would walk a client through. In a properly built HA cluster, OS patching is a rolling operation. You update one node at a time while the database stays up the whole way through, and Postgres itself never gets touched.

The shape is simple:

1. Build a fresh node image with the patched OS. Same Postgres version, same configuration, same everything above the OS. The only change is the layer you patch.
2. Roll it onto the replicas first. Stop Patroni on a replica, bring the node back on the new image, and let it rejoin the cluster and catch up on replication.
3. Once every replica is patched and healthy, trigger a controlled switchover. The primary role moves to a node that has already been patched.
4. Patch the old primary the same way. It comes back as a replica on the new image.

When it is done, every node runs the patched OS, and the only interruption anyone feels is a switchover measured in seconds, at a moment you pick. Compare that to a full reboot of a single primary, where you are down for however long the box takes to come back, at a moment the patch schedule picked for you.

Notice what never happened. Postgres was untouched. Same binaries, same config, same data files. The whole operation was about swapping out the ground the database stands on, and a cluster built for this makes that ground swappable without an outage. This is not a database upgrade. It is infrastructure maintenance that the database happens to ride through cleanly.

What Makes the Rolling Patch Actually Safe

The four steps look easy on paper. What makes them safe in production is the operational excellence around them, and this is usually where the difference between a real HA cluster and a hopeful one shows up.

Client connections have to follow the switchover. If your applications connect straight to a fixed primary address, a switchover just moves the outage instead of removing it. You want a routing layer in front: a load balancer, a connection pooler like PgBouncer, or a virtual IP that tracks the leader. That way, when the primary role moves, new connections land on the new leader without anyone rewiring anything.

Replication has to be caught up before you switch. Switching over to a lagging replica is switching over to a slow database, or worse. Check replication lag before you promote, and understand whether you are running synchronous or asynchronous replication, because that decides how much in-flight data a switchover can cost you.

Health checks and quorum have to be honest. Patroni makes its decisions based on what the cluster reports about itself. If a node comes back on the new image but its health check is lying, the cluster will trust it. Watch the rejoin, confirm the node is genuinely streaming and caught up, and keep enough healthy nodes in the cluster that you never lose quorum mid-patch.

The node image has to be reproducible. The whole model depends on the patched image being identical to the old one everywhere except the OS layer. If images drift, if one node has a different extension version or a different config, you will find out during a switchover, which is the worst possible time. Build the images from the same definition every time.

Test the switchover before you need it. A switchover you have never run is a plan, not a capability. Run a controlled one during a calm period, watch how the application handles it, measure the blip, and fix whatever surprises you. Then patch night is a repeat of something you already know works.

Where it Gets Complicated

I am not going to pretend a rolling patch is perfectly invisible, because it isn’t, and the honest version is more useful.

A switchover is not zero impact. In-flight transactions on the old primary get dropped, and there is a short window, usually a few seconds, where writes pause while the role moves. For most workloads, that is a blip. For something extremely latency-sensitive, you plan around it. Either way, it beats a full outage by a wide margin.

Some substrate patches want more than a reboot. A storage layer migration or a change to the underlying host can involve moving data, not just cycling an image, and that needs its own plan. The rolling model still applies; the steps just get bigger.

And the whole thing assumes you actually have a cluster. A single primary with no replica cannot do any of this. If your database is one node, OS patching genuinely is a maintenance window, and the real fix is the HA design, not the patch procedure. That is the honest prerequisite: rolling OS patching is something you build toward, and it is one of the clearest reasons to build proper HA in the first place.

The Bottom Line

Stop treating OS patching as a database maintenance window. It is a rolling operation on the stack underneath the database, and the database engine does not need to be part of it at all.

Build the cluster for it once. Reproducible node images, connection routing that follows the leader, healthy replication, a switchover you have tested. Do that, and patch night stops being a downtime event. You get to stay current on security patches on the schedule your compliance team wants, and your SLA never notices.

The last thing that took your database down probably was not the database. It was the ground it was standing on. Build for that, and you take that whole category of outage off the table.

FAQ

Do I need to patch Postgres to patch the OS? No. OS patching and Postgres patching are separate operations. In a rolling OS patch, you swap the node onto a patched OS image while keeping the exact same Postgres binaries, configuration, and data. The database engine is not part of the change.

Does a switchover cause downtime? A controlled switchover causes a brief pause, usually a few seconds, while the primary role moves to another node. In-flight transactions on the old primary are dropped and need to be retried. Compared to rebooting a single primary for an OS patch, the interruption is much shorter and happens when you choose.

What tools make rolling OS patching possible? An HA cluster manager like Patroni handles leader election and switchover. You pair it with a connection routing layer, such as a load balancer, a pooler like PgBouncer, or a leader-tracking virtual IP, so client connections follow the primary when it moves. Reproducible node images tie it together.

Can I do rolling OS patches with a single Postgres node? No. Rolling patches need at least one replica so the database stays up while you take each node out, patch it, and bring it back. If you run a single node, OS patching means an outage, and the fix is to build proper high availability first.

How do I keep client applications connected during the switchover? Put a routing layer between your applications and the database so they connect to the current leader rather than a fixed node. A load balancer, PgBouncer, or a virtual IP that tracks the primary all work. When the primary role moves, new connections land on the new leader without any application change.

Running Postgres where uptime is not negotiable? Stormatics builds and operates high-availability PostgreSQL clusters that patch, upgrade, and fail over without taking your database offline. Learn more about DBA as a Service or talk to us about your availability targets.