The impossible triangle of decentralized storage

We’re promised that decentralized storage will one day replace the giants’ cloud: your files scattered, encrypted, across the disks of thousands of strangers, with no company able to read them or cut them off. It’s a fine ideal, and I run a node to contribute to it. But there’s a hard limit the marketing never shows — a kind of triangle where you get to pick only two corners out of three.

The three corners

A decentralized storage system would like to combine three qualities.

Decentralization: no central operator, no one you can coerce, corrupt, or shut down.

Speed and usability: smooth enough that you actually use it, not just in theory.

And resilient metadata. That’s the one everyone forgets, and it’s the heart of the problem. Metadata is the index: the record of which file is split into which pieces, stored on which disks. Without that index, your data exists somewhere but you can no longer find it. So the index has to survive — and survive in a decentralized way, otherwise you’ve just moved the point of failure.

The trouble is you can’t have all three at once. Every serious project has quietly sacrificed one corner. Let’s compare the two most emblematic.

Storj’s choice: keep the index at the center

Storj bet on speed. To instantly find where your pieces are, it maintains central servers — called satellites — that hold the index. The result: it’s fast, usable, comparable to a real cloud. The storage itself is well distributed across thousands of independent nodes like mine.

But the index isn’t decentralized. And that has a consequence people rarely discover before it hurts: Storj’s survival isn’t a technical question, it’s a legal one. If the company operating the satellites disappears, the protocol doesn’t take over on its own — someone has to buy the entity and take over the satellites. Continuity runs through corporate law, not mathematics. Storj chose speed, and paid for it in coordination resilience.

Sia’s choice: put the index in the blockchain

Sia made the opposite bet: full decentralization. No satellites, no company at the center. The coordination — storage contracts, proofs, payments — is written into a blockchain, like Bitcoin’s. No one can shut it down. Better still: the protocol funds itself through its own token issuance, which makes its organization surprisingly unkillable — it keeps developing even when a far larger competitor goes through bankruptcy.

The price of that choice? First, slowness: coordinating through a blockchain is structurally slower than a central server — several times slower than an ordinary cloud, by the measurements. Then a subtlety about metadata: with Sia, part of the index lives on the client side, on your own access machine. The central point of failure is gone, but it has moved: if you lose your own access keys, you lose the thread to your data. Sia chose decentralization, and paid for it in speed and simplicity.

What the triangle teaches us

“Decentralized storage” isn’t one thing. It’s a family of trade-offs, and each project silently decided which of the three corners to sacrifice. Storj: fast and distributed, but its survival depends on an entity. Sia: unkillable and masterless, but slow and more fragile for the individual user. Neither is “the right one” in the absolute — they answer different priorities.

The useful reflex, here as elsewhere, isn’t to hunt for the perfect project. It’s to ask, in front of every decentralization promise: which corner was sacrificed, and does that suit me? Whoever sells you all three at once is hiding which one they dropped.

Me, I chose to run a Storj node — so, knowingly, speed and usability at the cost of a resilience that rests on a company. That isn’t blindness: it’s an owned trade-off, because I know where it falls short. And maybe that’s the only real skill in this field: not believing in the perfect tool, but knowing exactly what your own tool can’t do.

This reflection grew out of an exchange on the Storj forum, where I asked about the survival of a storage network beyond a single legal entity: the discussion thread.