Synchronous replication and the trade-off it makes · PostgreSQL

Asynchronous replication means a commit is durable on one machine. If that machine’s storage is destroyed between the commit and the standby receiving it, the transaction is lost while the client believes it succeeded.

Synchronous replication closes that window, and the price is not subtle.

The levels

synchronous_commit has five values. Two concern only local durability and were covered in lesson XII-01; three concern the standby.

Value	Commit returns when	Survives
`off`	WAL is in the buffer	Nothing. Crash loses recent commits
`local`	WAL is flushed locally	Primary crash. Not primary loss
`remote_write`	Standby’s OS has it	Standby process crash. Not standby host loss
`on`	Standby has fsynced it	Loss of either machine
`remote_apply`	Standby has replayed it	Same as `on`, plus read-your-writes

on is the default, and on a cluster with no synchronous_standby_names it means local flush only. Setting synchronous_commit = on does not make replication synchronous. Two settings are required.

The measured cost

Read-only / Safefour levels on the same pair, same standby, 20-second runs— EXECUTION VALIDATED on 18.6. pgbench -c 8 -j 4 -T 20. synchronous_standby_names = 'walreceiver' throughout; sync_state confirmed 'sync'.

$ pgbench -U postgres -c 8 -j 4 -T 20 postgres

  setting            tps      latency avg    relative
-----------------  -------  -----------    --------
local              1624     4.926 ms       100%
remote_write       1625     4.923 ms       100%
on (remote flush)  1474     5.428 ms        91%
remote_apply       1462     5.470 ms        90%

(asynchronous baseline, synchronous_standby_names empty:
 1618 tps / 4.940 ms — indistinguishable from 'local')

Read that table with its scope limit

Both containers run on one host. The network between them is a loopback bridge with sub-millisecond round trips.

Real synchronous replication across racks, availability zones or regions pays the network round trip on every commit, and that term dominates everything else. A 1 ms round trip adds 1 ms to every commit; a 10 ms cross-region round trip adds 10 ms, which on a workload committing every 5 ms is a threefold latency increase, not a 9% one.

This table shows the shape of the cost — that remote_write is nearly free locally, that on costs real throughput, that remote_apply costs a little more again. It does not show the magnitude you will see. Measure your own pair over your own network.

remote_write showing no cost at all is specifically a loopback artefact: the standby’s OS accepts the write essentially instantly here. Over a real network it costs the round trip like everything else.

Configuring it

# on the primary
synchronous_standby_names = 'standby1'
synchronous_commit = on

The name matches the standby’s application_name, which comes from primary_conninfo. Set it explicitly:

primary_conninfo = '... application_name=standby1'

Without it, the default is walreceiver for every standby, and you cannot distinguish them.

Read-only / Safeconfirming a standby is actually synchronous— EXECUTION VALIDATED on 18.6.

$ SELECT application_name, sync_state, sync_priority FROM pg_stat_replication;

 application_name | sync_state
------------------+------------
walreceiver      | sync

sync_state is the only trustworthy confirmation. Anything else is belief.

Quorum forms

synchronous_standby_names = 'standby1'                  # exactly this one
synchronous_standby_names = 'FIRST 1 (s1, s2)'          # s1 preferred, s2 fallback
synchronous_standby_names = 'ANY 1 (s1, s2, s3)'        # any one of three
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'        # any two of three

ANY 1 (s1, s2) is the form that makes synchronous replication survivable in practice, and the reason is the next section.

A single synchronous standby is an availability liability

With synchronous_standby_names = 'standby1' and that standby gone — crashed, network-partitioned, or simply stopped for maintenance — every commit on the primary blocks indefinitely.

Not slows. Blocks. The primary accepts connections, runs queries, and hangs on COMMIT. To an application it looks like a total outage, and pg_stat_activity shows backends waiting on SyncRep.

This is not a bug. It is the guarantee working: you asked that no transaction be acknowledged unless it is safe in two places, and it is not safe in two places. But the arithmetic is worth stating plainly: one synchronous standby makes you strictly less available than no replication at all, because now two machines must be up instead of one.

The mitigations, in order of preference:

ANY 1 (s1, s2) with two standbys. Either one satisfies the requirement, so losing one costs nothing.

Monitor sync_state and alert on its absence. The failure begins the moment no standby is synchronous.

Have a documented, rehearsed procedure to drop to asynchronous. ALTER SYSTEM SET synchronous_standby_names = '' plus a reload releases every waiting backend within seconds. It is the right call during an outage and it must be an explicit decision, taken knowing the RPO is now non-zero — never a reflex, and never something a script does on its own.

What must not be in that procedure is promoting the standby and hoping, or restarting the primary to clear the block. Both replace a recoverable situation with an unrecoverable one.

When it is warranted

Synchronous replication is right when losing an acknowledged transaction is worse than being unavailable: payments, ledgers, regulatory records, anything where “we told them it succeeded and it did not” is the worse outcome.

It is wrong when availability matters more than the last few transactions, which is most systems. A well-monitored asynchronous standby with lag measured in milliseconds — as measured in lesson XIV-04, 2.5 ms at 1,623 tps — has an RPO of milliseconds without the availability coupling.

There is a middle path that is often the right answer: synchronous_commit is a per-transaction setting.

-- most work: asynchronous, fast
SET synchronous_commit = local;

-- the transactions that must not be lost
BEGIN;
SET LOCAL synchronous_commit = remote_apply;
INSERT INTO payments ...;
COMMIT;

The cost is paid only by the transactions that need it. On a system where 1% of commits are financially significant, that is a 1% cost instead of a 9% one.

What a waiting backend is actually doing, and why the WAL is already there

A backend committing under synchronous replication writes and flushes its WAL locally first, exactly as it would otherwise. Then, instead of returning, it adds itself to a queue and sleeps, waiting for the walsender to signal that a standby has confirmed the required LSN.

Two facts follow, and both matter during an incident.

The transaction is already committed locally and will not be rolled back. The wait is purely about acknowledgement. If the primary crashes while backends are waiting, those transactions are in its WAL and are recovered on restart, having never been acknowledged to any client.

Cancelling the wait does not cancel the transaction. Pressing Ctrl-C, or calling pg_cancel_backend(), releases the backend and returns — with a warning that the transaction’s status is unknown to the standby:

WARNING:  canceling wait for synchronous replication due to user request
DETAIL:  The transaction has already committed locally, but might not have
         been replicated to the standby.

That warning is precise and it is the whole hazard in two lines. The client now believes the transaction may have failed, while it is committed on the primary and will become visible everywhere the moment the standby reconnects. This is exactly the ambiguity synchronous replication exists to prevent, reintroduced by the escape hatch.

Which is why clearing a synchronous stall by cancelling backends one at a time is the wrong instinct. Changing synchronous_standby_names and reloading releases every waiting backend at once, with the primary now honestly asynchronous, and no transaction left in an ambiguous state.

What to take from this

synchronous_commit = on alone changes nothing. synchronous_standby_names is what makes replication synchronous.
remote_write / on / remote_apply buy standby-OS, standby-disk and standby-visibility guarantees respectively.
Measured on a loopback pair: 9% throughput cost for remote flush. Over a real network the round trip dominates. Measure yours.
One synchronous standby makes you less available than none. Use ANY 1 (s1, s2).
Alert on sync_state, and rehearse dropping to asynchronous as an explicit decision.
synchronous_commit is per-transaction. Pay the cost only where it buys something.

Cross-course references

Linux for Production Sysadmins — Part LII (High availability fundamentals) and Part LIII (Quorum and split brain) cover the same trade between durability and availability, and why a quorum of one is a single point of failure wearing a quorum’s clothes.
Observability for Production Sysadmins — Part LIX (Database observability) covers alerting on sync_state, because a cluster silently demoted to asynchronous reports nothing.