Synchronous Replication and Quorum Commit

The one thing to understand first

By default PostgreSQL replication is asynchronous: a primary commits once its own WAL is durable, without waiting for any standby. If the primary then fails before a standby received the latest WAL, those last transactions are lost. Synchronous replication makes the primary wait for standby confirmation before reporting commit success, eliminating that data-loss window — at the cost of commit latency.

Synchronous replication trades latency for durability — but if you don't provision enough standbys, it secretly also trades away availability: the same "wait for confirmation" that prevents data loss will hang every commit when there's no one left to confirm.

Layer 3 — Watch it happen on your own database

One catalog tells you which standbys are actually counting toward your durability guarantee:

SELECT application_name, sync_state, sync_priority, state, replay_lsn
FROM   pg_stat_replication;
-- sync_state: 'sync', 'potential' (standby), or 'async'
SHOW synchronous_standby_names;

A standby listed in synchronous_standby_names shows sync_state = sync; spares waiting to be promoted into the quorum show potential; everything else is async. If you expect a synchronous standby and see only async rows, your zero-data-loss guarantee is not actually in force — and commits may be silently running async or about to block.

Layer 4 — The levers this hands you

Two GUCs give you fine control over the durability/latency/availability balance. First, synchronous_commit sets how much confirmation each commit waits for — and it is per-transaction settable, so most traffic can run async while only critical writes demand more:

• off — don't even wait for local disk flush (fastest, can lose recent local commits on crash).
• local — wait for local WAL flush only; ignore standbys (this is async replication).
• remote_write — wait until the standby has written WAL to its OS (not necessarily fsynced).
• on — wait until the standby has flushed WAL to disk (default meaning of synchronous).
• remote_apply — wait until the standby has replayed the WAL, so a read on that standby sees the transaction (read-your-writes on replicas).

Second, synchronous_standby_names picks which standbys count and how many must confirm — and this is where you defuse the availability trap:

-- FIRST: the named standbys in priority order; the first 1 to confirm counts
synchronous_standby_names = 'FIRST 1 (s1, s2, s3)'

-- ANY: any 2 of the listed standbys must confirm (quorum commit)
synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

• The availability trap: if the required number of synchronous standbys are unavailable, commits block — the database appears to hang. With FIRST 1 (s1) and one standby, losing it stops all writes.
• The fix is enough nodes: at least three with ANY 1 (s1, s2) or ANY 2 (s1, s2, s3), so one standby can fail without blocking commits while still guaranteeing the data is on a second machine.
• FIRST k prefers specific standbys by priority; ANY k is more resilient because no single standby is mandatory.
• Place synchronous standbys with low network latency to the primary; cross-region sync is painful.

Layer 5 — What an Oracle DBA should expect vs what they get

Synchronous replication maps onto Data Guard's protection modes, with quorum commit as the notable addition:

• **synchronous_commit = on ≈ Data Guard SYNC (Maximum Availability),** and remote_apply ≈ real-time apply where the standby is query-consistent — but in Postgres you choose this per transaction, not just per-database.
• The availability trap is the same lesson as Maximum Protection mode: Oracle's Maximum Protection will shut down the primary if no standby can confirm. Postgres instead blocks commits — equally an outage if you lack quorum. Both demand spare standbys.
• **Quorum commit (ANY k) has no direct classic Data Guard analogue** — it is closer to the quorum model of Oracle's far-sync/observer setups, and it is the recommended way to get zero-loss without a single mandatory standby.
• No separate licence. Synchronous replication and quorum commit are built in and free, unlike the editions/options gating around Oracle's higher protection modes.

Key takeaway

Synchronous replication eliminates the data-loss window by making the primary wait for standby confirmation, with synchronous_commit choosing how strong the wait is and synchronous_standby_names choosing who confirms. The trap is that requiring confirmation from too few standbys turns durability into an availability liability — use ANY k quorum with enough spare standbys so one failure never blocks commits, and reserve the strictest levels for transactions that truly need zero loss.