A permissioned blockchain only earns its place when several organisations that do not fully trust each other need to share a record none of them controls alone. If every participant belongs to the same company, a database with an audit trail delivers the same outcome for a fraction of the cost.
After building Hyperledger Fabric networks for industrial traceability, the lesson that stuck is less technical than you would expect. The hard part was never the chaincode. It was governance between the participating organisations.
The three-question test
Before any proof of concept, answer honestly:
- Is more than one organisation writing to the record? If not, stop here. You want a database.
- Do those organisations have conflicting interests? Supplier and buyer, insurer and repair shop, producer and certifier. If they are all departments of the same company, a sysadmin solves this with permissions.
- Would anyone accept being the owner of the database? If everyone agrees company X hosts and administers it, you have a contract problem, not a technology problem.
Three yeses and the case is real. One no and the answer is probably PostgreSQL with an audit table and digital signatures.
What Fabric genuinely delivers
Unlike public networks, Hyperledger Fabric is permissioned. Participants hold identities issued by a certificate authority, there is no mining and there is no cryptocurrency. What it offers:
- A shared, replicated record that no single organisation can alter after the fact.
- Channels, so only a subset of participants sees certain transactions. Competitors can sit on the same network without seeing each other’s volumes.
- Endorsement policies. You define how many and which organisations must sign a transaction for it to count. This is where the real value lives.
- Executable contracts in Go or Node.js, without the language constraints of public chains.
What it does not deliver
Worth being blunt, because expectations tend to arrive inflated.
It does not validate the physical world. If someone types “organic coffee” for a batch that is not organic, the network records that lie with perfect integrity, forever. Blockchain guarantees the data was not tampered with after it was written. It guarantees nothing about whether it was true before.
It is also not fast. Consensus between organisations costs latency, so keep it off the critical path of a user-facing screen. And it is not easy to operate: certificate authorities, MSPs, channels, orderers, coordinated contract upgrades across companies. This is serious infrastructure and it needs people to maintain it.
Finally, it does not solve data protection law. An immutable record and personal data get along badly. Personal data stays off the ledger. The hash goes on it.
Where it works well
The cases that survived in practice share a pattern: a supply chain with multiple links and a need to prove something to a third party, whether an auditor, a certifier or a regulator.
Origin traceability, environmental footprint calculated from data supplied by several vendors, settlement between operators, provenance certification. In those cases the value is not in the word “blockchain”. It is in having a number that nobody in the chain can change alone and that an auditor can verify without asking any of the parties for a favour.
The architecture that tends to work
In the deployments that survived their first year, the shape is always similar. The application runs normally on a relational database, and the entire user experience comes from there. Only the events that need proof between organisations go to the shared ledger, which is usually a small fraction of operations. Documents and personal data stay outside, in ordinary storage, with only the hash and a pointer on the ledger. Writes happen asynchronously through a queue, so if the network is slow the user never feels it.
Put the blockchain at the centre of the application and you build a slow system on a poor database. Put it at the edge, as a proof layer, and you build a normal system with one extra guarantee.
Need this solved at your company?
A twenty minute call is usually enough to tell whether it makes sense, and you talk straight to the engineer who builds it.