How Storage Changes PostgreSQL Commit Latency Under Sustained Load

Short answer: PostgreSQL commit latency depends on more than a volume's best-case fsync. In Nirvana's 100,000-checkpoint agent benchmark, ABS recorded roughly half the PostgreSQL commit p99 of the tested AWS storage configurations. At moderate load, however, AWS io2 and gp3-16k held the lower per-commit tail. The useful question is where your own write path crosses from isolated commits into sustained queueing.

What does PostgreSQL wait for at COMMIT?

With synchronous_commit=on, PostgreSQL waits for the transaction's WAL record to reach durable storage before reporting success. That protects committed work, but it puts storage latency directly in the application path. The PostgreSQL documentation describes the trade-off between synchronous and asynchronous commit.

The single-write floor matters, but so do concurrency, WAL behavior, checkpoints and the queue that forms when many workers commit together. A storage tier can win an isolated fsync test and lose once the workload runs long enough to sustain pressure.

What did the benchmark actually test?

Nirvana's LangChain write-path benchmark ran identical 4-vCPU, 16-GB machines with 256-GB volumes. Each agent checkpoint included a PostgreSQL INSERT + COMMIT, a Redis write and a Qdrant upsert. PostgreSQL used synchronous_commit=on on every platform.

The pure-write mode measured checkpoint cycles. Mixed mode first read context, then committed new state. Results were repeated three times at 1,000, 10,000 and 100,000 checkpoints. The published end-to-end result covers the complete three-service cycle, so it should not be presented as a PostgreSQL-only benchmark.

When did ABS pull ahead?

100K steady-state metric	Nirvana ABS	AWS range
PostgreSQL commit p99, write mode	105–107 ms	210–232 ms
PostgreSQL commit p99, mixed mode	79–82 ms	158–175 ms
Raw QD=1 fsync latency	1.13–1.91 ms	0.97–2.80 ms

At 10,000 checkpoints, io2-32k and gp3-16k produced the best per-operation commit tail at 78–88 ms, versus 95–105 ms on ABS. At 100,000 checkpoints, the order reversed. ABS held 105–107 ms in write mode while the AWS configurations reached 210–232 ms.

That is evidence of a sustained-load advantage in this configuration, not a claim that every PostgreSQL transaction is faster on Nirvana. It also preserves the unfavorable raw result: io2 delivered the lowest measured fsync latency.

What should you measure in your workload?

Start with transaction p50, p95 and p99 while the target number of writers is active. Record commits per second, WAL bytes, checkpoint timing, storage latency and queue depth in the same windows. Include replicas if production commits wait on them.

Test long enough to separate a short burst from a stable operating state. Small development runs can hide the point where a fixed IOPS ceiling begins to accumulate work. Keep durability settings identical across every option.

How should you compare storage options?

Use the same PostgreSQL version, schema, transaction size, connection count and synchronous_commit setting. Run a moderate-load case and the sustained production target. Include recovery time and the full monthly cost required to meet the latency objective.

Read the full methodology and results, then bring a representative PostgreSQL workload for a matched test.

FAQ

Does the fastest fio fsync guarantee the fastest PostgreSQL commits?

No. It measures an important floor, but application concurrency, WAL activity, checkpoints and queueing determine the sustained result.

Should I turn off synchronous_commit?

Only if the acknowledged durability trade-off is acceptable. PostgreSQL notes that asynchronous commit can lose recently acknowledged transactions after a crash. Do not change it merely to improve a benchmark.

Does this prove every PostgreSQL workload is faster on Nirvana?

No. It supports the published checkpoint pattern on the tested machines and scales. Read-heavy, replica-bound or lightly loaded systems may behave differently.

What is the strongest measured result?

At 100,000 steady-state checkpoints, ABS recorded PostgreSQL commit p99 of 105–107 ms in write mode and 79–82 ms in mixed mode, roughly half the tested AWS ranges.

---

About Nirvana Labs

Nirvana Labs is a high-performance storage cloud purpose built for blockchain, AI and databases i.e. the most demanding, real-time, stateful workloads. Accelerated Block Storage (ABS) offers 20K baseline IOPS included, no over provisioning. Nirvana Kubernetes Service (NKS) with Karpenter auto-scaling, high clock-speed compute and private networking. Backed by Jump Trading, Crucible, etc with 50+ customers live in production today.

Learn more at Nirvana Labs

Nirvana Cloud | Pricing | Blog | Docs | Changelog | LinkedIn | Twitter | Telegram | YouTube