# 7.1.1 The Durability Gradient (synchronous_commit)
In a distributed cluster, the definition of a "Permanent Record" is not a binary state. Postgres allows you to tune the exact moment a transaction is considered successfully committed, trading off **Durability** for **Performance**.
This is controlled by the `synchronous_commit` setting.
## The Spectrum of Certainty
When an application sends a `COMMIT` command, the primary node must decide how many "echoes" it needs to hear from its replicas before it tells the user "Success."
1. **`off` (Async/Local)**: The primary returns success as soon as the WAL is in the buffer, without waiting for the disk `fsync`. This is the fastest setting but carries a risk of losing the last few milliseconds of data in a crash.
2. **`local`**: The primary waits for the local disk to confirm the `fsync` has finished. Replicas are ignored for the commit decision.
3. **`remote_write` (Sync/Memory)**: The primary waits for the replica to acknowledge that it has received the WAL and written it to its **operating system memory** (but not necessarily to its disk).
4. **`on` (Default Sync)**: The primary waits for the replica to confirm the WAL has been **bolted down to disk** (`fsync` performed on the replica).
5. **`remote_apply` (Sync/Visible)**: The primary waits for the replica to confirm the WAL has been **replayed**. This ensures that anyone reading from the replica immediately after the commit will see the change.
## The Cost of the Echo
Every level of certainty adds **Latency**.
If you use `synchronous_commit = on`, every single transaction must pay the **Network Round-Trip Time (RTT)** to the replica. If your replica is in a different data center 10ms away, your minimum transaction time is now 10ms, regardless of how fast your CPU is.
> [!IMPORTANT]
> **Wait Event Analysis**: In `pg_stat_activity`, a process waiting for a synchronous commit will show the wait event **`SyncRep`**. If you see this event dominating your workload, your network is the bottleneck, not your database.
## Choosing Your Safety
| Level | Risk | Performance | Use Case |
| :------------- | :---------------------------- | :---------- | :-------------------------------------------- |
| `off` | Loss of ~10-100ms on crash | Extreme | Non-critical logs, transient state. |
| `local` | Loss of data if Primary dies | High | Standard async replication; focus on speed. |
| `on` | Data is safe if Primary dies | Medium | Financial transactions; high-value records. |
| `remote_apply` | Zero "Read-Your-Writes" lag | Low | When replicas MUST be identical to primary. |
By understood the durability gradient, you can ensure that your database is only as slow as your data's value requires it to be.
---
| ← Previous | ↑ TOC | Next → |
| :--- | :---: | ---: |
| [[Chapter 7/7.1 - The Many Shouting Elephants (Read Replicas)\|7.1 Read Replicas]] | [[Learn You a Postgres for Great Good\|Home]] | [[Chapter 7/7.1.2 - Hot Standby Feedback (xmin horizon)\|7.1.2 Hot Standby Feedback]] |