Every fast write moves work somewhere else
This article explores the architectural trade-offs in database storage engines regarding write durability and latency. It highlights how different systems balance the speed of memory-based writes against the safety of local SSDs or remote object storage.
Why it matters
Understanding these trade-offs is critical for engineers designing high-performance, fault-tolerant distributed systems.
Every storage engine has to decide what must finish before it tells a client that a write succeeded. The quickest answer is to return after copying the bytes into memory. A local durable write waits for fdatasync() on an SSD in the database host. Keeping the write after that host disappears means waiting for a network volume, an object store, or several database servers to save their own copies.
Those choices move latency and durability together because returning after memory is fast, but a machine crash can lose the write. Waiting for a local SSD survives a process or kernel crash, but not the loss of that device or host, while remote storage or several database servers can survive more failures by putting network and copy time into every write.
Get smarter about the news
Sign up free for a feed built around what you actually care about, Dive Deeper research on any story, and the full text of every article.
Create free accountAlready have an account? Sign in