Designing a planned switchover for minimum disruption
When a Neki shard's primary has to step aside for a pod replacement, kernel upgrade or cell move, PlanetScale does a planned switchover instead of stopping Postgres the way Patroni does, so a failed switchover can quickly fall back to the old primary. Admin, Neki's control plane, first validates shard state, the target replica, logical failover slots and Postgres settings. Routers then proactively buffer primary-bound queries, the primary defaults new transactions to read-only, and the other replicas are disconnected to pin a final WAL position the target must replay. If the target can't catch up before a deadline, a config reload makes the old primary writable again. Buffered queries are replanned against the new primary, so apps see added latency instead of errors, and every acknowledged commit is on the target when it is promoted.
The same sharded Postgres was pushed to 118.5M QPS across 512 shards in PlanetScale's benchmark. More: how other teams scaled Postgres.
- Published
- 2026-10-29
- Scale
- one primary and multiple replicas per shard, synchronous replication ANY 1 across eligible replicas
- Techniques
- planned switchover query buffering synchronous replication preflight validation rollback
- Stack
- PostgreSQL Neki Kubernetes
Try this stack yourself
- Railway · Deploy something like this on Railway: spin up PostgreSQL plus your app in a few clicks. New accounts get $20 in credit (applied when you pick a paid plan).
Railway isn't part of PlanetScale's setup in this story. It's just an easy place to try the same building blocks.
Some links above are affiliate links: if you sign up, How They Scaled may earn a commission at no extra cost to you. We only list tools that fit the stack in the story.