Question: Write-ahead log
Can I lose data with synchronous_commit off?
Answered in the first paragraph. Last updated .
Yes, and only in one way. A crash can lose transactions that were already reported to the client as committed, within a window the documentation bounds at three times the log writer’s interval, which on the defaults is well under a second. What you cannot lose is consistency: the database comes back in the state it would have been in if those transactions had rolled back cleanly. That distinction is the entire point of the setting.
The guarantee that survives
Turning this off changes when the client is told the commit is durable, not whether the log is written correctly. There is no torn state, no half-applied transaction and no corruption, because the ordering rules that protect the data files are untouched. The documentation says so explicitly, and contrasts it with the setting that does risk inconsistency, which is the one that disables the write barrier entirely.
So the honest description of the risk is a short amnesia, not damage. Whether that is acceptable is an application question with a real answer, and for a great many workloads the answer is yes.
Where it earns its keep, and how to apply it precisely
It is set per transaction and per session, which is the part people miss. You do not have to choose one policy for the cluster. A bulk load, a queue of derived rows, an analytics ingest or a cache refresh can run with it off while the transactions that move money keep the default, in the same database, at the same time.
That per-transaction control is also the answer to the usual objection. If the application cannot express which transactions matter, the setting is too blunt and should stay on; if it can, this is one of the largest write throughput improvements available for no hardware.
One thing it is not. On a cluster with a synchronous standby the same setting names the level of acknowledgement to wait for, so the values are about a remote flush or a remote apply rather than a local one. Synchronous commit covers those levels, and what happens when a synchronous standby goes down covers what the strongest of them costs in availability. If the reason for reaching for this is that commits feel slow, check first whether they are waiting on a standby rather than on local storage, which replication lag and slot health covers measuring.