Relationship · Vulnerable To
Source: Workload·Target: Failure Mode
Summary
Write-heavy transactional workloads generate high WAL volume that can saturate WAL writer throughput, fill the WAL buffer, and: in the extreme: cause write transactions to block waiting for WAL to be flushed to disk or consumed by replicas.
Evidence
- ·PostgreSQL WAL write throughput is bounded by disk fsync speed: NVMe SSDs support 1-5 GB/s; spinning disk 100-200 MB/s
- ·wal_buffers default (4MB before PostgreSQL 12) is frequently exhausted under high write load
- ·Synchronous replication adds replica I/O as a WAL saturation multiplier: each synchronous replica must confirm WAL receipt
- ·Replication slot WAL retention fills disk if a replica disconnects: WAL accumulates indefinitely
- ·PostgreSQL pg_stat_bgwriter.buffers_checkpoint / buffers_clean ratio indicates WAL I/O pressure
Operational Context
- ·Set wal_buffers=64MB for write-heavy workloads: default auto-tuning is conservative
- ·Monitor pg_current_wal_lsn() - pg_last_wal_receive_lsn() across replicas: gap indicates WAL production exceeds consumption
- ·Set max_slot_wal_keep_size to prevent replication slots from accumulating unlimited WAL
Tradeoffs
- ·Increasing wal_buffers improves burst write performance but consumes more shared memory
- ·synchronous_commit=off reduces WAL durability window (last 200-400ms of commits unconfirmed on crash)
- ·Logical replication slots (CDC) hold WAL longer than streaming replication: additional WAL retention risk
Evidence grounding
Grounded, 5 supporting itemsWAL saturation is a documented PostgreSQL scaling limit for write-heavy workloads. Disk I/O throughput, synchronous_commit settings, and replica replication slot management are the primary operational levers.