When is decentralised storage genuinely the right choice over a normal database?

Short answer

Use decentralized storage when the important property is verifiable, content-addressed data that should survive one company or server. Use a database when the product needs updates, permissions, search, deletion, transactions or operational control.

What content addressing buys

In a content-addressed system the identifier of a file is derived from the bytes of the file — a hash, wrapped in a small amount of metadata about how it was chunked and encoded. That single change has three consequences worth naming precisely.

The identifier verifies the content. Given an identifier and some bytes, anyone can check locally that the bytes are the ones the identifier names, so it does not matter who served them to you. Fetching from an untrusted peer is safe in a way that fetching from a URL is not.

The identifier is not a location. It says what you want, not where it is, which is why the same file stored by twenty independent parties has one identifier rather than twenty URLs. Nobody has to agree on a namespace, and nobody controls one.

And the identifier is immutable by construction. Change a byte and you have a different identifier. There is no version of this scheme in which a file is edited in place, which is the property that makes it useful for records and awkward for almost everything else.

What it does not buy, and this is where candidates thin out

An identifier existing does not mean the content exists. Most content-addressed networks are retrieval protocols, not durability guarantees: a file is available while at least one node holds it and is willing to serve it. Keeping content available means pinning it somewhere you control or paying a service to pin it, and if that ends, the data can become unfetchable while the identifier remains perfectly valid. Storage networks that add incentives — paid, contract-backed persistence — exist precisely because the base layer does not provide it, and they change the assumption from "someone is being nice" to "someone is being paid until a date". Neither is the same as a durable store you administer.

There is no query capability. You can fetch by identifier and that is the entire interface. There is no "all documents uploaded last week by this user", no ordering, no aggregate and no partial read of a structured record, so any application need beyond retrieval requires an index elsewhere — which is a database, holding the identifiers.

Mutability has to be manufactured. Since the identifier changes with the content, "the current version of this document" needs a mutable pointer to an immutable object: a naming layer, or more usefully a smart contract or a database row holding the latest identifier. That pointer is now the thing that has to be trustworthy, and its trust model is whatever you built, not the storage network's.

Latency and access control are the last two. A cold fetch from an unfamiliar peer is not comparable to a read from an object store in your own region, and content addressing has no notion of a permission — anyone with the identifier and a route to a provider has the bytes. Encrypting before storing works, and moves the problem to key distribution and to the fact that stored ciphertext cannot be retracted when a key leaks.

Requirement	Content-addressed store	Managed object store	Relational database
Verify bytes were not altered	Yes, by construction	Only if you hash separately	Only if you hash separately
Survive the company disappearing	Possible, if pinned by others or paid for	No	No
Query, filter, aggregate	No	No	Yes
Mutate in place	No	Yes	Yes
Delete on request	Not reliably	Yes	Yes
Predictable low latency	Varies by provider and peer	Yes	Yes

Where it is genuinely right

The strong cases share a shape: bytes that must be verifiable, must not change, and must outlive the party that published them.

Token and asset metadata is the canonical one. An NFT whose metadata is a plain URL is an NFT whose properties the issuer can rewrite after sale; a content-addressed identifier means the buyer holds a reference to exactly the file they were shown. Documents anchored by a contract are the same argument — legal terms, an audit report, a governance proposal — where what matters is that the version people voted on is provably the version that is served. So is the frontend of a protocol that claims credible neutrality: publishing the built application by content identifier means users can verify they are running the code that was audited, rather than whatever your CDN is currently returning.

Large public datasets with many independent mirrors fit too, because the deduplication and the verifiability both do real work: many parties want to host the same corpus and none of them wants to be trusted about its contents.

Where a database wins, without argument

Anything mutable, anything queried, anything private, anything a regulator can compel you to erase. User profiles, order history, session data, messages, personal information of any kind. The last of these is not a performance judgement but a legal one: a right to erasure and a storage layer where deletion is not reliably achievable are in direct conflict, and encrypting-then-discarding-the-key is a mitigation you should expect to have to defend rather than a settled answer.

The pragmatic architecture for most products is therefore both, with a clear rule about which data goes where. Verifiable, immutable artefacts go in content-addressed storage; a database holds the identifiers, the metadata, the permissions and the search index; and the application reads from the database and fetches bytes by identifier when it needs them.

Gateways quietly reintroduce what you removed

The detail that undoes many of these designs is the gateway. Browsers do not speak these protocols natively, so applications fetch through an HTTP gateway — and a single hosted gateway is exactly the centralised, rate-limited, blockable dependency the design was meant to avoid. When that gateway is slow, your verifiable data is unavailable; when it is down, users conclude the asset is gone.

It is not a reason to abandon the approach, but it is a reason to be honest in the interview about what has been achieved. Content addressing has made the data verifiable and replaceable in source, which is a genuine and useful property: any gateway will do, and a client can check the bytes. It has not, on its own, made delivery decentralised. The follow-up an interviewer reaches for is whether your users can still get the file if your gateway of choice disappears tomorrow, and the good answer is a list of independent providers plus a verification step in the client, not a claim that the problem does not exist.

Content addressing is an integrity mechanism first and a storage mechanism second. Choose it for data whose provenance must be checkable by a stranger, and keep everything you need to query in a database.

---

© 2026 Preptima. Originally published at preptima.com.