Key takeaways
- The only thing a blockchain provides that a database cannot is agreement among parties who do not trust one administrator.
- If a single organisation controls the data, a database is faster, cheaper and easier to fix.
- Blockchains cannot verify that recorded information was true when written, which undermines many supply chain pitches.
- Honest test: name the parties who distrust each other and cannot agree on an operator. If you cannot, you do not need a chain.
Almost every industry has now been told that blockchain will transform it. Comparatively few of those transformations arrived. The reason is not that the technology fails to work. It is that the problem it solves is narrower than the marketing suggests, and most organisations do not have that problem.
This piece tries to be useful rather than promotional. A blockchain does one thing that conventional systems cannot, it charges heavily for it, and knowing where that trade lands is worth more than any list of possible applications.
The one thing a blockchain uniquely provides
Reduced to essentials, a public blockchain lets parties who do not trust one another agree on a shared history without appointing anyone to be in charge of it. Every other property people cite, including cryptographic integrity, timestamping, append-only logs and audit trails, is available from ordinary software. Signed, hash-linked audit logs are decades-old technology.
What is genuinely hard without a chain is removing the administrator. In any normal system, someone holds the write privileges and could in principle alter records. Usually that is fine, because contracts, regulators, auditors and reputation constrain them. A blockchain is for situations where those constraints are absent or where the parties’ interests conflict enough that nobody accepts a single operator.
That capability is not free. Compared with a competent database, a public chain is dramatically slower, more expensive per write, harder to query, more difficult to change, worse for storing anything private, and constrained by data protection rules that assume records can be deleted.
Where it genuinely helps
Bearer digital value across borders
The original application remains the strongest. A digital asset that can be held and transferred without a specific institution’s permission, with a supply schedule nobody can quietly change, cannot be reproduced by a database because a database has an owner who could change either. Whether one values that property is a separate question, but the property is real. The security behind it comes from the cost of attacking the network, which is why hashrate and difficulty are worth watching on our dashboard.
Settlement between parties without a common intermediary
When institutions in different jurisdictions need to settle obligations and no single clearing house serves them all, a shared ledger neither controls can shorten a chain of correspondents. The benefit is not speed for its own sake but the removal of reconciliation between separate books.
Rules that must be credibly beyond anyone’s discretion
Some arrangements are valuable precisely because no party can override them. Escrow with no releasing authority, or issuance that cannot be expanded by a decision, are examples. Here immutability is the feature. Anywhere the ability to intervene would be reassuring rather than alarming, you want a database.
Public verifiability of a commitment
Publishing a hash of a document or dataset to a public chain creates an independently checkable record that the content existed in that exact form at that time, without revealing the content. This is a modest, useful pattern, and it typically requires only a handful of transactions rather than an entire platform.
Where a normal database wins
Anything a single organisation controls
Internal records, customer data, inventory, logistics within one company: if you own the system, a chain adds cost and removes capability. You lose fast queries, easy schema changes, the ability to correct errors and straightforward deletion. Those are not incidental losses.
Provenance claims about physical goods
The pitch is appealing: track produce or components from origin to shelf so nothing can be faked. The gap is at the first step. Someone must attach a digital identifier to a physical object and assert what it is. If that assertion is wrong, whether by error or fraud, the chain preserves it faithfully forever. The hard part of provenance is physical verification, and no ledger performs it. Blockchain can harden the record of an already-trustworthy inspection regime. It cannot substitute for one.
Personal data of any kind
Immutability and privacy regulation pull in opposite directions. Rights to erasure and correction assume records can be changed. Putting personal data on an append-only distributed ledger creates a compliance problem that is architectural rather than procedural. Storing only hashes helps, but pseudonymous data can often be re-identified, so this needs care rather than reassurance.
High-volume, low-value transactions
Payment processing at retail scale, ad serving, telemetry and similar workloads involve throughput and per-item costs that conventional infrastructure handles far more cheaply. Layered systems built on top of chains improve this, but they do so partly by keeping most activity off the chain, which rather makes the point.
Voting in public elections
Elections need verifiability and ballot secrecy simultaneously, plus resistance to coercion and reliance on ordinary voters’ insecure devices. A public ledger addresses tabulation integrity while making the other problems harder. Serious election security work concentrates on paper records and risk-limiting audits for good reasons.
A short test
Before adopting a chain, answer four questions plainly. Who are the parties, and do they actually distrust each other? Is there any operator they would all accept? What breaks if you use a shared database with strong audit logging? And is the data already digital and native to the ledger, or does someone have to vouch for the physical world?
If there is an acceptable operator, or if the answer depends on human attestation anyway, the chain is decoration. That conclusion is unfashionable but it saves a great deal of money.
Why the honest version matters
Overstating the technology has a cost. Pilots that were never suited to a ledger fail, and the failure gets attributed to the technology rather than the fit. Meanwhile the applications where distributed consensus genuinely earns its keep get lumped in with the rest.
The defensible position is narrow and durable: blockchains are the right tool when you must coordinate without an administrator and are willing to pay real costs for it. Everywhere else, use the boring thing. For definitions see the glossary, for background reading see learn, and for how we assess claims see our methodology.
Frequently asked questions
What is the single question that decides whether a blockchain is appropriate?
Ask who would run the database, and whether every participant would accept that choice. If there is an operator all parties are content to trust, use a database. It will be faster, cheaper, easier to query, easier to correct and easier to comply with privacy law. A blockchain earns its considerable costs only when no acceptable operator exists, when participants have genuinely competing interests, and when the ability to verify history independently is worth the loss of performance and flexibility. Most projects fail this test, which is why so many pilots quietly become ordinary systems.
Doesn't a blockchain guarantee that supply chain data is accurate?
No, and this is the most persistent misunderstanding in the field. A chain guarantees that a record has not been altered since it was written and that participants agree on ordering. It says nothing about whether the record was true at the moment of writing. If someone scans a label attached to the wrong goods, the chain preserves the error permanently and with cryptographic authority. Physical verification still depends on inspections, audits and trusted attestation. The chain can strengthen an existing trustworthy process; it cannot manufacture trustworthiness where none exists.
Are private or permissioned blockchains a good middle ground?
Sometimes, but they need scrutiny. If a permissioned network has a small number of members who could simply agree on a shared operator, it is a database with extra steps. Where they can make sense is between organisations that genuinely compete, need a shared record, and want each party able to verify the log independently rather than take another firm's word for it. Even then the honest comparison is against a well-run shared database with strong audit logging, not against no system at all. Ask what specifically breaks if you use the simpler option.
Exploring blockchain, crypto, and DeFi innovation. Ex-fintech analyst turned journalist, spotlighting real-world use cases of blockchain. Writer at Cryptocurrency Miners.
