Synchronous replication: 2 real scaling case studies

2 of the 94 engineering write-ups in our database are tagged with the technique "synchronous replication". They come from 2 companies (Datadog and PlanetScale) and were published in 2026. Stack that shows up most often in these stories: Kubernetes (2) and PostgreSQL (2). 2 of the 2 state concrete scale numbers, for example "one primary and multiple replicas per shard" (PlanetScale). Each card below links to our short summary and the original post.

PlanetScale · 2026

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.

one primary and multiple replicas per shardsynchronous replication ANY 1 across eligible replicasplanned switchoverquery bufferingsynchronous replicationPostgreSQLNekiKubernetes
Datadog · 2026

When failover isn't safe: Building high-availability PostgreSQL on Kubernetes

A gameday that injected network latency into one availability zone left several of Datadog's Kubernetes-based PostgreSQL clusters stuck: replicas lagged past Patroni's maximum_lag_on_failover, so no standby could be promoted safely. Datadog moved to a hybrid model: standbys in the leader pool take part in synchronous replication (one synchronous standby, synchronous_mode_strict, synchronous_commit=remote_apply) while read replicas stay asynchronous. pgbench showed remote_apply raised average latency by 53% and cut throughput by 34%, yet production clusters saw no measurable impact after a gradual rollout, and synchronous replication is now enabled in all of its clusters.

+53% avg write latency with remote_apply (pgbench TPC-B)-34% tps with remote_apply (pgbench TPC-B)synchronous replicationfailoverhigh availabilityPostgreSQLKubernetesPatroni

Get new synchronous replication scaling stories weekly

One email a week. No spam.

Companies in these stories

Browse all 105 topics →