Replicación síncrona frente a asíncrona

Physical streaming replication can run in two modes: asynchronous (the default) and synchronous. They differ in when the primary considers a commit complete.

In async mode the primary commits as soon as the WAL is flushed locally. It does not wait for the standby. This is fast but a crash can lose the most recent commits not yet shipped.

In sync mode the primary waits until at least one standby confirms it received (or applied) the WAL before reporting commit success. This guarantees zero data loss for confirmed commits at the cost of extra latency.

Name your standbys with application_name and list them in synchronous_standby_names on the primary.

You can require any N of several standbys to confirm, balancing durability and availability.

The synchronous_commit setting controls how far a commit must travel:

• off / local — local only
• remote_write — standby received WAL
• on — standby flushed WAL to disk
• remote_apply — standby applied WAL (visible on replica)

This setting can be changed per transaction, letting unimportant writes go fast while critical writes wait for confirmation.

If the only synchronous standby goes down, commits on the primary will block until a standby returns. Always pair sync replication with multiple candidates or quorum settings.

Inspect the live state from the primary using pg_stat_replication.

Use async for throughput and geographically distant replicas. Use sync when losing even one committed transaction is unacceptable, such as financial ledgers.

Synchronous commit latency is roughly the network round-trip to the standby plus its fsync time. Keeping sync standbys on a low-latency link is essential.

What is the key trade-off of synchronous replication?

You compared asynchronous and synchronous replication, configured synchronous_standby_names and synchronous_commit levels, and learned the durability-vs-latency-vs-availability trade-offs.