eduKate Singapore

VIEW THIS AS

Auto mode follows the Route Engine until you choose a viewpoint.

YOU ARE HERE

ROUTE CHECK

CONNECTED TO

WHAT NEXT

Use the canonical route for this room, or HELP if you are unsure.

Next useful routeCanonical hubHELP

Blockchain vs Traditional Databases: Choosing the Right Record System

—

by

eduKate Asia
Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.

中文版 · Blockchain learning guide · Previous: What is blockchain?

Blockchain learning · Article BC002

Three students in school uniforms work through open books at a classroom table, with textbooks and stationery nearby and study notes on the whiteboard behind them.
Study photograph for illustration; it does not establish that the pictured students are studying blockchain.

Choose a record system by its responsibilities, not its fashionable label. A conventional database is usually the first option to assess when one organisation can legitimately administer the records. A blockchain becomes a stronger candidate when independent participants need to coordinate permitted changes without giving one participant unilateral control over the accepted history.

That is a starting point, not an automatic verdict. Databases can be replicated, audited and shared. Blockchains still need software, access arrangements and governance. The useful comparison is between two complete designs for the same job, including what happens during mistakes and failures.

This guide explains how to make that comparison. Its examples concern equipment bookings and document verification, not financial trading. You can work through the exercises using a paper checklist; no account, token or real-world deployment is needed.

Choose your reading route

In this guide

  • Choosing for one organisation: read the requirements test and the database-first example.
  • Coordinating several organisations: examine shared control, failure scenarios and the consortium example.
  • Checking a vendor proposal: use the comparison criteria, pilot plan and decision memo.
  • Learning for an assignment: follow the full argument, then complete the exercise and answers.

Back to contents · Next section

1. Define the job before selecting the system

“Build a blockchain platform” is an implementation direction. It is not a clear description of the problem. A useful problem statement identifies a record, an action and the people affected.

For example: “Three training centres need to reserve a shared set of laboratory instruments, avoid conflicting confirmed bookings and investigate disputed changes.” That statement leaves room to compare solutions. It also distinguishes a booking problem from a certificate-verification problem or an inventory problem.

Next, state the observable outcome. Does a user need an immediate provisional response, a confirmed reservation, an independently checkable history or all three? Can a temporary conflict be resolved by a coordinator, or would that violate the purpose of the arrangement?

Finally, say what the system does not decide. A reservation record cannot determine whether an instrument is safe, whether a learner is qualified to operate it, or whether a centre complied with a physical inspection procedure. Those tasks need their own evidence and controls.

This requirements-first method is editorial guidance. It is deliberately practical: write the job in ordinary language so that a proposed architecture can be tested against it.

Back to contents · Next section

2. Separate three kinds of trust

Trust in the operator concerns who administers the system. Can this organisation delete records, change permissions, restore backups or provide different views to different users? What contractual, technical or institutional controls constrain it?

Trust in participants concerns the organisations submitting information. Do they sometimes make mistakes? Could they deliberately submit a misleading booking cancellation or backdated explanation? Does one organisation benefit from another being denied access?

Trust in inputs concerns how the record connects to reality. A barcode scan, inspection result or signed statement can still be wrong. Neither a database nor a blockchain eliminates this problem merely by storing the input.

A team may trust a university to administer bookings while distrusting individual users to report usage accurately. In that case, better validation and audit procedures may matter more than changing the storage architecture. Conversely, several institutions may accept each other’s signed requests while refusing to let one of them unilaterally rewrite the shared sequence.

The phrase “we do not trust each other” is therefore too vague. Specify the action you do not want another party to control and the evidence needed to detect misuse.

Back to contents · Next section

3. Compare complete designs, not stereotypes

A weak comparison sets a carefully engineered blockchain against a single unprotected spreadsheet. That does not establish which architecture is appropriate. The alternative should include the controls that a competent database design would normally consider.

For a database proposal, describe authentication, permissions, transaction handling, backups, audit logging, monitoring and administrator oversight. If independent parties need receipts, explain whether signed exports or independently retained acknowledgements could meet that requirement.

For a blockchain proposal, describe membership, validation, ordering, participant operation, application permissions, data access and software upgrades. Identify the services outside the chain: websites, identity systems, document storage, notification providers and support teams.

Both proposals need a credible recovery procedure. Both also need someone to pay operating costs and maintain integrations. A diagram with many nodes does not make these responsibilities disappear.

NIST’s Blockchain Technology Overview, published in October 2018, is a foundation for the blockchain side of this comparison. Its terminology should not be used to assume that every contemporary system has the same control structure.

Back to contents · Next section

4. The first decision: is one accountable administrator acceptable?

Suppose one training centre owns its equipment, sets the booking rules and accepts responsibility for resolving disputes. Staff and learners need reliable access, but outside institutions do not need to independently approve the official record.

A conventional database is a strong starting candidate. It can support the application while the centre defines who may create, cancel and correct bookings. Audit records and backups address different needs: investigation and recovery. The design still requires careful implementation, but no multi-organisation consensus requirement has yet been established.

Adding a blockchain does not necessarily remove the administrator. If the same centre controls every validator, every administrator key and the only website, the apparent distribution may not create meaningful independence. The important question is what a user can verify or preserve when that centre acts incorrectly.

There may be a reason to add independently witnessed commitments or signed receipts without moving the entire booking workflow onto a chain. Treat this as another candidate design, not a compromise to dismiss because it lacks a dramatic label.

Back to contents · Next section

5. The second decision: what must independent parties control together?

Now change the scenario. Three independently governed centres contribute equipment. Each wants to prevent another from quietly rewriting the accepted booking order. None is willing to appoint one centre as the sole final authority.

This requirement makes jointly governed infrastructure worth evaluating. A permissioned ledger is one candidate. A shared database under an agreed neutral operator, accompanied by signed acknowledgements and external audit, is another.

The choice turns on more than the number of organisations. Can they agree on admission rules? Which changes require which approvals? Who operates the ordering service? What happens if one participant stops maintaining its systems? Can a departing organisation retrieve the records it is entitled to retain?

Hyperledger Fabric provides one concrete example of separating endorsement, ordering and validation within a permissioned architecture. The configuration and governance chosen by an actual deployment remain essential. Fabric introduction.

A useful warning sign is a proposal that promises distributed control but leaves all upgrades and recovery actions with the vendor. That may be an acceptable managed service, but the claimed benefit must match the actual allocation of power.

Back to contents · Next section

6. Eight comparison criteria that expose the tradeoffs

Control and independent verification

Ask what each participant can check without asking the current operator for permission. A downloadable report is not automatically proof that earlier records were never selectively omitted. Equally, a ledger is not useful evidence to someone who cannot obtain or interpret the required data.

Error correction

Specify how an incorrect reservation is corrected and how the original action remains explainable. An overwrite, a reversal and an additional correction entry have different effects. The right design depends on the audit and privacy requirements, not a universal preference for keeping everything forever.

Privacy and access

List the minimum information each role needs. A participant may need to see available equipment without seeing another centre’s internal timetable or learner details. Do not assume that restricted writing implies restricted reading, or that hashed personal data is automatically anonymous.

Availability and recovery

Test loss of an operator, a hosting region or a signing key. Identify whether users can still read records, create requests and confirm changes. Those three capabilities may fail differently. Recovery arrangements should state who acts and how the recovered state is checked.

Performance at the required outcome

Compare time to the outcome the user actually needs. A quick “received” response cannot be compared fairly with a confirmed, durable booking. State transaction complexity, load and failure conditions alongside any throughput measurement.

Integration and usability

The system must work with existing identity, scheduling and reporting processes. If staff must retype every booking into two systems, the new ledger may increase errors even while strengthening one narrow integrity property.

Governance and maintenance

Document who approves releases, handles incidents and resolves disagreements over policy. Include how decisions are recorded and communicated. A technically distributed service can still depend on a single overworked maintainer.

Total cost and exit

Include implementation, integration, operation, review, training, support and eventual migration. Ask whether records can be exported in a usable form and whether verification remains possible after a vendor contract ends. A low transaction fee is not a complete operating budget.

Back to contents · Next section

7. Worked example: a database-first equipment service

Consider a hypothetical centre, North Workshop, with one equipment manager and internal users. The centre owns the instruments and has authority to approve bookings. Users want prompt confirmations and a way to challenge a cancellation.

Its requirements can be expressed as three checks: two users must not receive conflicting confirmed bookings; authorised staff must be able to correct mistakes with an explanation; and the centre must be able to recover after a service failure.

A database-backed application can be evaluated against those requirements. The proposal should show how concurrent booking requests are handled, how staff permissions are constrained and how changes are retained for review. It should also demonstrate backup restoration rather than merely claiming that backups exist.

What would blockchain add here? Perhaps an externally witnessed record of booking changes would help investigate administrator misconduct. But that requirement needs to be stated and assessed. If no independent party actually verifies the record, operating several nominal nodes may add complexity without resolving a current problem.

A reasonable provisional decision is database-first, with a documented route to stronger external evidence if a real need emerges. This is a conclusion about the stated scenario, not a claim that a single organisation can never benefit from ledger-based verification.

Back to contents · Next section

8. Worked example: the three-centre consortium

Now imagine North Workshop, East Laboratory and River Training share a scarce instrument. Each contributes resources and each wants evidence that confirmed allocations cannot be silently rearranged by a rival.

Begin with governance rather than software. Suppose they agree that a booking follows a shared allocation policy, disputed changes require a recorded explanation, and no single centre can unilaterally change the policy. Those agreements are necessary whichever technology they choose.

Candidate A is a neutral managed database. An accepted operator runs the service. Participants receive signed acknowledgements and periodic records for independent review. Its main question is whether that operator’s authority and oversight are acceptable.

Candidate B is a permissioned ledger. The centres operate or oversee distinct roles and use defined approval rules. Its main question is whether the actual implementation prevents the unilateral changes the participants are concerned about, while still functioning under expected outages.

Candidate C is an existing booking service with contractual audit rights. This may offer less direct verification but lower operational burden. If the perceived distrust is minor and institutional remedies are adequate, it deserves consideration.

Do not choose a winner by counting technical features. Test each candidate against the same disputed-booking scenario. If all three centres later decide that a neutral operator is acceptable, the justification for the more complex arrangement may change.

Back to contents · Next section

9. When a signed document is enough

Some projects do not need shared updates at all. They need recipients to verify who issued a statement and whether it has been altered.

Imagine an adult training provider issuing a completion certificate. A verifier needs to identify the issuer, inspect the claim and check relevant validity or status information. That does not automatically require every certificate to be written onto a public blockchain.

W3C’s Verifiable Credentials Data Model separates issuer, holder and verifier roles and allows different arrangements for registries. Blockchain is optional. The Recommendation dated 15 May 2025 is a useful starting point for this distinction. W3C Verifiable Credentials Data Model v2.0.

The design must still address issuer legitimacy, status changes, privacy and availability. A valid signature from an untrustworthy issuer does not make the qualification valuable. Choosing a credential standard and choosing a storage architecture are related decisions, but they are not the same decision.

Back to contents · Next section

10. Run a pilot that could change your mind

A useful pilot is allowed to show that the preferred design is unsuitable. Define acceptance conditions before building, so that a polished demonstration does not replace evidence.

For the booking scenario, test simultaneous requests for the same slot. Does the system preserve the intended allocation rule? Then disconnect one participating service. Which operations still work, and what do users see?

Next, introduce an incorrect entry and use the planned correction procedure. Can a reviewer understand both the mistake and the correction? Revoke a test account’s permission and check whether it can still perform actions it should no longer control.

Finally, export the records and attempt a recovery in a separate test environment. Can the team reconstruct the usable state without undocumented help from one vendor employee? Use synthetic data and dummy credentials throughout the pilot.

These tests are an editorial checklist, not a certification standard. Add the requirements of the actual application. Their purpose is to expose operational assumptions that a normal success-path demonstration might hide.

Back to contents · Next section

11. Write the decision in one page

A concise decision memo can contain five short parts.

  1. Problem: the record being coordinated, the parties involved and the consequence of disagreement.
  2. Required guarantees: what must remain true, who must be able to verify it and under which failures.
  3. Alternatives: the strongest practical database, signed-record and ledger designs considered.
  4. Evidence: pilot results, unresolved limitations and the reason the selected option best fits the requirements.
  5. Review trigger: a change that would justify revisiting the choice, such as new participants, stronger audit needs or unacceptable maintenance burden.

Avoid declaring that the chosen architecture is “future-proof.” A better decision explains its assumptions. When those assumptions change, the team can revisit the design without treating earlier work as a failure.

Back to contents · Next section

12. Common comparison mistakes

“Databases can be edited, so they cannot be trusted.” The relevant questions concern permissions, controls, auditability and independent evidence. Unrestricted silent editing is a design flaw, not a necessary property of every database application.

“Several replicas mean decentralised governance.” Copies improve some availability properties, but the same administrator may control all of them. Count independent authority, not just machines.

“A blockchain removes the need for agreements.” Participants still need to agree on membership, software changes, responsibilities and disputed real-world claims.

“Public visibility is always better.” Disclosure can expose unnecessary information. Determine what evidence the verifier needs, then minimise unrelated data.

“The cheapest transaction wins.” A transaction fee omits integration, operation, correction, governance and exit costs. Compare a complete workflow over its useful life.

Back to contents · Next section

Check your understanding

Scenario A: One museum owns a collection database. It wants reliable backups and an internal audit trail. No external participant needs to jointly control updates. What should it assess first?

Answer: A conventional database with appropriate access, audit and recovery controls. A blockchain proposal needs an additional requirement that explains its extra complexity.

Scenario B: Several independent institutions reject unilateral control by any one member and need to verify a shared sequence of authorised updates. Is a permissioned ledger automatically the winner?

Answer: It is a candidate, not an automatic answer. Compare governance, failure behaviour, privacy and total cost with a neutral operator or other signed-record arrangements.

Scenario C: A recipient only needs to verify the issuer of a document. Must the document be onchain?

Answer: No. Digital signatures or verifiable credentials may meet the need. The system still requires credible issuers and suitable status, privacy and availability arrangements.

Final exercise: Name one fact that would reverse your preferred choice for the equipment example. A strong answer changes a requirement, such as all participants accepting a neutral administrator, rather than merely introducing a new platform name.

Back to contents · Next section

Frequently asked questions

Can a database and a blockchain be used together?

Yes. An application can keep operational records in a database while using signed statements or ledger commitments for a specific verification need. The important task is defining which component is authoritative for each question and how inconsistencies are handled.

Is a permissioned blockchain just a slow database?

That label is too broad to be useful. Inspect whether it gives distinct organisations meaningful shared control or verification that they actually require. If those benefits are absent, its additional coordination cost may be difficult to justify.

Does “traditional database” mean one server?

No. Database systems can be distributed or replicated. The relevant distinction here is control and verification arrangements, not simply whether more than one machine stores data.

What should a beginner learn next?

Study the difference between distributed operation and decentralised authority. Then examine one transaction rule and one recovery procedure in a concrete system. Those details make architectural comparisons more reliable.

Back to contents · Next section

Sources and scope

This guide’s comparisons and hypothetical pilots are editorial synthesis. The underlying technical reference was researched on 12 October 2026, Asia/Singapore. Source publication dates are preserved below. The guide does not assess the legality of a particular deployment or recommend a financial service.

Choose the simplest complete design that satisfies the real requirements, and keep enough evidence to explain why it does.

Back to contents

Next: Distributed Systems vs Blockchain: What the Extra Rules Change