synchronous_commit has five settings

synchronous_commit decides how far a transaction’s log record must get before the server reports success to the client. Its default flushes the record to local durable storage first. Turning it off lets the commit return immediately and flushes shortly afterwards. The other three values extend the requirement to a standby, at the point the standby has received, flushed or replayed the record. It can be changed for a single transaction, which is the part most descriptions leave out.

Off loses commits, not consistency

Turning it off is often described as unsafe in a way that suggests corruption, and that is not what happens. The log is still written in order and recovery still replays it in order, so the database comes back consistent. What can be lost is a small window of the most recently acknowledged commits, bounded by how often the server flushes. For a queue of derived rows that can be recomputed, that is a reasonable trade for a large throughput gain. For a payment it is not, and the useful part is that both can run on the same server because the setting is per transaction.

The bigger trap is in the other direction. The three values that name a standby require synchronous_standby_names to have been set. Without it there is no synchronous standby to wait for, so a server configured with the strictest-looking value behaves exactly like the default and nobody notices, because the only difference is a guarantee that was never being provided.

Reading the five values from the server

The catalog carries the list and the scope in one row.

SELECT name, setting, enumvals, context FROM pg_settings WHERE name = 'synchronous_commit';

        name        | setting |                 enumvals                 | context 
--------------------+---------+------------------------------------------+---------
 synchronous_commit | on      | {local,remote_write,remote_apply,on,off} | user
(1 row)

local is the value people reach for last and often want first: it keeps the local flush and waives the wait for the standby, which is what you set when a synchronous replica is down and writes have stopped. The context column says user, meaning any session can change it for itself and any transaction can change it for its own commit, with no restart, no reload and no privilege.

Choosing a level per workload

The decision is per transaction class rather than per cluster, so the practical work is identifying the transactions whose loss would be recoverable and relaxing only those. Where a synchronous standby is involved, the level interacts with how lag is measured and with what happens when the standby falls behind, both of which are covered in replication lag and slot health. The three positions a record passes through on the way to a standby are the subject of write, flush and replay lag.