Jun 2026
Durability is a rate, not a number
Eleven nines of durability is not a promise that your data survives. It is a bet about how fast you can rebuild.
When a storage vendor sells you "eleven nines" of durability, they are not telling you your data will survive. They are telling you a probability per year: 99.999999999%. Lose one object out of a hundred billion annually and the marketing still holds. The number is real. The thing it measures is not the thing you think it is.
Durability is not a property of stored bytes. It is the outcome of a race. On one side, disks die. On the other, the system copies the survivors onto fresh disks before the last copy goes dark. Whoever is faster wins. Eleven nines is just a claim that the rebuild wins almost every time. Change the rates and the nines move.
The race is between failure and repair
Picture a file split into 9 data shards and 3 parity shards, scattered across 12 disks. You can lose any 3 and reconstruct the whole thing. Lose a 4th before you repair the first 3 and the file is gone. So the question that actually decides durability is not "how reliable is a disk." It is "how long does a disk failure stay unrepaired."
That window is mean time to repair, MTTR. And MTTR is not a constant. It depends on how much data sat on the dead disk, how many other disks can feed the rebuild in parallel, how much network you are willing to spend, and whether three other disks are already rebuilding and starving the same pipes. Durability falls out of the ratio between MTTR and mean time to failure. Shrink the repair window and the nines climb. Let repairs queue up behind each other and the nines collapse, quietly, while the dashboard still says eleven.
This is why a 20 TB drive is scarier than a 2 TB drive even when both have the same annualized failure rate. The big drive holds ten times the data, so rebuilding it takes ten times longer, so the dangerous window where a second failure can finish you off is ten times wider. Same failure rate, worse durability. The number you were quoted assumed a repair speed nobody wrote on the invoice.
Correlated failures eat the math alive
The eleven-nines calculation almost always assumes failures are independent. They are not. A bad batch of drives from one manufacturer fails on the same schedule. A rack loses power and takes 40 disks at once. A botched firmware push bricks a fleet in an afternoon. A datacenter floods. When failures correlate, the comfortable assumption that you would never see 4 deaths inside one repair window stops being true, because the 4 deaths arrive together.
This is the real reason serious systems spread shards across racks, across power domains, across availability zones. Not because any single disk is more reliable that way, but because it breaks the correlation. You are not buying more reliable hardware. You are buying independence between the things that can kill you, so that the rate of simultaneous loss stays far below the rate at which you can repair.
What this means when you design
Stop treating durability as a sticker on the box and start treating it as a budget you spend continuously. The levers are concrete. More parity shards widen the gap before loss, at the cost of storage overhead. More disks feeding each rebuild shrink MTTR, at the cost of network. Smaller blast radius per failure domain breaks correlation, at the cost of placement complexity. Every one of those is a knob on the failure-versus-repair race, and every one of them shows up in the nines.
The honest limit is that you can never actually verify eleven nines. To measure a rate that low you would need to observe billions of object-years and watch zero of them die, which means the number is always a model, never a measurement. It is only as true as its assumptions about failure rates, repair speed, and independence, and the first thing reality does is break those assumptions. Treat the quoted figure as the answer to a math problem, then go ask what inputs the problem used.
So the next time someone quotes you a durability number, ask the better question. Not "how many nines." Ask "how fast do you repair, and what happens to that speed when a whole rack dies at once." That answer is the durability. The nines are just its shadow.
So we made repair the product
Verse treats durability as the race, not the sticker. A heal daemon exists for one job, win the rebuild, and the knob that matters is the low-water mark, because it sets the exponent on time-to-loss, not the raw copy count. Replication is demand-driven, hot data spreads itself toward where it is used. And we are blunt about the proof: a node can show it still holds a copy, but that is a deletion detector, not a guarantee of independent copies, so independence comes from placing replicas on distinct keys and repairing fast. Faster repair, not more nines on a slide.