All Resources
R-52
Technology
Content-Addressed Identity Ends the Integer-ID Drama
Auto-incrementing IDs feel obvious until you've spent a sprint reconciling them across two systems. Cryptographic hashes solve the problem at the source.
PAR2 Labs
August 29, 2026
1 min
We've never met a senior data engineer who loves auto-incrementing IDs. We've met many who tolerate them. The unspoken truth is that the moment a record exists in two systems, integer IDs become a category of bug that compounds forever.
01
What “content-addressed” means in practice
Every fact in Tessera has an ID derived from its content with a BLAKE3 cryptographic hash. Identical inputs produce identical IDs — across machines, across time, across rebuild cycles. The ID isn't assigned. It's computed.
02
Three things this kills
Duplicate detection becomes free. Re-ingest a fact you already have? Same content → same ID → the existing record. No upsert dance, no LEFT JOIN on natural keys.
Cross-system references become natural. When system A and system B both compute the ID from the canonical content, they're talking about the same row without coordination.
Tamper detection becomes a property of the data. Change the content, the ID changes. Audit trails self-verify.
Identical inputs produce identical IDs — across machines, across time, across rebuild cycles.
03
The tradeoff worth flagging
Content-addressed IDs are deterministic, not sequential. You can't ORDER BY id and expect insertion order. You can't generate a customer-facing reference like “Order #1247” from the hash. Both are fine if you stop confusing the database's identity with the application's display number. Most teams realise within a week that they were conflating those two things and never look back.
Integer IDs aren't a feature. They're a 1970s implementation detail we inherited because nobody had cheap, collision-resistant hashing in the database layer.
04
Why BLAKE3
Cryptographically strong, parallelisable, and fast on every architecture we care about, with a multihash-style encoding so the hash family isn't welded into downstream code. SHA-256 would have worked too; BLAKE3 was the better fit for how often we hash.
Key Takeaways
01
Every Tessera fact has an ID computed from its content with BLAKE3, so identical inputs give identical IDs everywhere.
02
Duplicate detection, cross-system references and tamper detection all follow from the ID itself.
03
Hash IDs are not sequential: insertion order and customer-facing numbers belong to the application, not the identity.
PAR2 Labs · Technology
Work With Us