Member-only story
How to Scale PostgreSQL to 100,000 Writes Per Second Without Sharding
When engineering teams hit write-throughput walls in PostgreSQL, the default architectural reflex is often distributed sharding (Citus, manual application partitioning, or migrating to NoSQL).
Sharding introduces massive operational debt: two-phase commits, broken cross-shard foreign keys, tricky distributed transactions, and complex schema migrations.
Before introducing multi-node sharding, modern hardware and deliberate tuning of PostgreSQL’s engine mechanics can push a single primary instance past 100,000 writes per second.
Achieving this requires eliminating disk sync bottlenecks, batching engine operations, reducing index update overhead, and tuning PostgreSQL’s Write-Ahead Log (WAL).
1. Eliminate the Per-Write fsync Bottleneck
By default, PostgreSQL prioritizes durability over raw throughput. Every transaction commit executes an fsync() syscall, forcing disk platters or NVMe controller caches to flush WAL data to non-volatile storage before acknowledging success.
A fast NVMe drive can handle 10,000 to 40,000 IOPS. It cannot handle 100,000 individual blocking fsync() calls per second from independent threads.
