Why this matters
Every organization that stores or shares data faces one question: is the data I am looking at the data that was stored? Most databases cannot answer it. A record is modified, a file is overwritten, and nothing says so. Content addressing answers the question at the lowest level, by deriving each resource's identity from its content.
What it is
In a content-addressed system, the identity of a piece of data is a cryptographic hash of its bytes. Instead of storing data at a location, such as a row id, a file path or a URL, the system computes a fixed-length fingerprint from the data itself. That fingerprint is the address.
Change one bit and the hash changes. The old hash still names the old content. Nothing is overwritten.
Git works this way: every commit is a hash. So do package managers with their integrity checks, and peer-to-peer file systems. The idea is old. Applying it to a company's operational data is not.
How it works
- Write. Data enters the system and the system hashes the stored bytes. In Legra those bytes are encrypted before they are stored, so the hash names ciphertext.
- Store. The data is kept under its hash. The hash is the only way to fetch it.
- Read. A request names a hash. The system checks the bytes it returns against the address, so corruption and tampering show up on every read.
- Link. References between pieces of data are hashes, not locations. A link keeps pointing at the same content wherever that content lives: a local disk, a remote server, a peer.
Not a checksum
A checksum is verification after the fact. You store the data, compute a checksum on the side, and hope somebody compares them later. Content addressing makes verification structural: the address is the checksum. A fetch is a check. There is no separate step to skip.
What it gives you
Tamper evidence by default. Any change to stored data changes its hash. The property needs no audit layer, no ledger and no trusted third party.
Deduplication for free. Two systems that hold identical data hold identical hashes, so the data is stored once. In a network where many nodes keep overlapping data, that saves storage, bandwidth and time.
Links that do not break. In a location-addressed system, moving or renaming data breaks every reference to it. A content-addressed link points at what the data is, not where it sits. Data can move between servers, regions or organizations and every reference still resolves.
Cheap synchronization. Two nodes that want to agree exchange hashes to find what is missing, then transfer only that. Data present on both sides is skipped. Even a slow or intermittent link works.
History for free. Because addressed content does not change, each version can point at its predecessor by hash. The chain is the history, and anyone who holds it can check it. Legra builds its history this way.
What it costs
A different mental model. You do not update a content-addressed resource; you create a new version with a new hash. Something has to map human names, such as a branch or a label, to the current hash.
Hashing. Every write pays for a hash. Modern hash functions are fast, but the cost is real in a high-volume pipeline.
Growth. If every version is kept, storage only grows. A retention policy decides what may go, without breaking the chain for what stays.
Keys. Combined with encryption, as it should be, the hash covers the ciphertext. Key rotation and revocation then become operational tasks of their own.
What to ask
Is the hash the address, or just a checksum? A hash kept in a separate column and not used for retrieval is a checksum. The check is weaker.
Which hash function? Older functions have known collisions. The choice should be current and documented.
Is identical content stored once? If not, the system is not fully content-addressed.
Can data move without breaking references? This is the practical test. If moving data to another server means updating references, the system is location-addressed underneath.
How is change handled? Look for a clear layer that maps mutable names to immutable hashes. A system that lets one hash name different content over time has broken the model.
Try it in Legra
For a first hands-on task, load a small named graph and query the records you uploaded.