cloud —

Designing a planned switchover for minimum disruption

Shlomi Noach | October 29, 2026 A Neki shard consists of one Postgres primary and multiple replicas.

Designing a planned switchover for minimum disruption

The primary accepts writes; the replicas do not. From time to time, we need one of those replicas to take over as the primary.

We may be replacing a (Kubernetes) pod, upgrading the kernel, or moving the primary to another cell. This is what we call a planned switchover.

As opposed to an unplanned failover, which happens when there is unexpected server disruption, it is a routine operation that comes at an unavoidable cost: there is some period of time where Neki cannot reliably route writes to either the old or the new primary. In this post we discuss how Neki minimizes that period, how it keeps applications from experiencing errors, and what happens if the switchover cannot complete. We can break down a planned switchover into three parts: The first part takes place while the primary is still serving normally.

Earlier coverage

Reported by Lobste.rs.

cloud

Related coverage

Elsewhere in this edition