Synchronous vs Asynchronous

Async replication favors throughput and low commit latency; sync replication narrows RPO at the cost of standby latency and availability sensitivity.

Recipe

Default async on primary; add one sync standby for tier-0 data.

-- Async (default): commits return when local WAL is flushed
ALTER SYSTEM SET synchronous_commit = 'on';
 
-- Sync to one named standby
ALTER SYSTEM SET synchronous_standby_names = 'FIRST 1 (standby1)';
SELECT pg_reload_conf();

-- On standby: set application_name to match synchronous_standby_names
ALTER SYSTEM SET cluster_name = 'standby1';
SELECT pg_reload_conf();

When to reach for this: You need zero or near-zero committed transaction loss on primary failure and can accept added commit latency.

Working Example

Measure sync impact and verify partner state:

-- Primary: inspect sync partners
SELECT application_name, sync_state, sync_priority, write_lag, flush_lag, replay_lag
FROM pg_stat_replication;
 
-- Session-level durability trade-off (bulk load window)
SET synchronous_commit = 'off';
COPY staging.events FROM '/data/events.csv' CSV;
RESET synchronous_commit;

# Benchmark commit latency async vs sync (pgbench)
pgbench -h primary.db.internal -U app -c 4 -j 4 -T 30 -S appdb
pgbench -h primary.db.internal -U app -c 4 -j 4 -T 30 -S appdb \
  --sync-method=strict

What this demonstrates:

• synchronous_standby_names picks which standbys count toward quorum.
• sync_state = 'sync' confirms the partner participates in synchronous commits.
• synchronous_commit = off speeds bulk loads but widens RPO for that session only.

Deep Dive

How It Works

• Async: Primary returns COMMIT after local WAL flush (per synchronous_commit). Standby catches up later.
• Sync: Primary waits until required standbys flush (and optionally apply) WAL before COMMIT returns.
• synchronous_commit levels: off, local, remote_write, remote_apply, on (maps to synchronous_standby_names quorum).
• FIRST n (...) means any n listed standbys satisfy quorum; ANY n (...) is an alternate quorum style in PostgreSQL 18.

RPO and RTO Snapshot

Patroni 3.x Note

Patroni sets synchronous_mode and manages synchronous_standby_names during failover. Test Patroni sync config in staging before production; a lost sync standby can stall writes.

Gotchas

• Two sync standbys without latency budget - Commit waits on slowest geo replica. Fix: At most one sync partner unless you model WAN RTT.
• Sync partner down - Writes hang if quorum cannot be met. Fix: Patroni failover policy or temporarily reduce synchronous_standby_names.
• synchronous_commit = off globally - Fast but RPO widens for all sessions. Fix: Scope to maintenance windows or batch roles only.
• Misnamed application_name - Standby never becomes sync partner. Fix: Match names in pg_stat_replication.application_name.
• Confusing sync with logical replication - Different protocol and guarantees. Fix: Physical sync is WAL quorum; logical is change stream.

Alternatives

FAQs

Related

• Streaming Replication Basics - setup
• Replication Slots - WAL retention
• Patroni & etcd/Consul - sync mode automation
• DR Basics - RPO/RTO definitions

Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.