Enterprise
How do you decide between a shared ledger and a database?
The question that should end most blockchain evaluations in the first meeting.
The answer
Ask whether any single party in the system could legitimately hold the authoritative record and have every counterparty accept it. If yes, build a database — it is cheaper, faster, and easier to audit. A shared ledger earns its cost only when several parties who do not trust each other must agree on a sequence of events and no one of them may hold the only copy.
The test, applied honestly
Most enterprise architectures have a party who could hold the authoritative record: the bank in a settlement system, the issuer in a loyalty programme, the operator in a marketplace. Where that party exists and every counterparty would accept its record, a shared ledger adds a trust assumption the system did not need and a reconciliation problem it did not have.
Where the answer flips
Multi-party supply chain events with no single custodian. Interconnect settlement between carriers who will not run each other’s database. Asset issuance where the register itself is the product being sold to a party who cannot be asked to trust the issuer’s own system. In each case, no one party’s record is acceptable to everyone else, which is the actual definition of the problem a ledger solves.
What we will say in writing
This practice has ended architecture engagements at this question before a single line of Solidity was written, because the honest recommendation was a database. That outcome is cheaper for the client and it is the reason the recommendation is trusted on the engagements where the answer is yes.
Talk to the practice
Tell us what you are trying to build and what has to be true for it to work.
Contact