Why Postgres wants NVMe on the hot path, and S3 everywhere else

Postgres commit durability requires WAL flushes that block until the kernel confirms the write is durable. On NVMe this takes tens of microseconds; on object storage like S3 it can be orders of magnitude slower. This latency difference directly caps OLTP throughput, especially at lower concurrency where group commit doesn't help. MVCC internals (tuple versioning, full-page writes, vacuum, hint bits) further amplify small scattered I/O, making fast local storage essential on the hot path. S3 excels at WAL archiving, base backups, snapshots, and feeding analytics pipelines — jobs that don't touch the commit path. PostgreSQL 18's async I/O improvements are designed to drive fast local storage harder, not to close the gap with object storage. The recommended architecture keeps NVMe (or fast block storage) on the commit and cache-miss path, and pushes cold, reconstructable state to S3.