Everybody is building their write-ahead log on S3 now. Turbopuffer, Chroma, and WarpStream are all doing versions of the same trick. Here’s what they are doing and how…
The old assumption was that a WAL needs a local disk followed by a replication across nodes for prevention against data loss. The WAL + S3 pattern flips it.
A write only counts as committed once it lands in S3, not before. So nodes stay stateless; they only cache in NVMe or RAM, and any node can serve any namespace/data since nothing durable lives on it and everything is on S3.
Two S3 properties make this work: strong read-after-write consistency, and conditional writes (If-None-Match). That second one lets multiple writers coordinate an ordered log without a leader election protocol like Raft sitting in front of it.
The cost is latency.
A single object storage round trip is tens of milliseconds, so nobody writes one record per S3 call. Everyone batches writes and flushes on a timer, and accepts commit latency in the range of 100 to 200ms.
This is why it matters - we need not worry about replication topology, not about leader failover, not about disks to provision ahead of load; nothing.
S3 storage becomes the thing you trust; everything else is just a stateless cache in front of it.