← all simulations
slide 4 · fundamentals
Blockchain vs conventional database
database · updateold value gone
balance = 40
ledger · appendhistory kept
+100
−60
+0
Run the same UPDATE and DELETE on both and compare what is left behind.
- 1Run UPDATE on both sides
- 2Run DELETE on both sides
- 3Look at what history survived
live · 0 players in this room
send coins to another player
10.0000 BTC10.0000 ETH
recipient
waiting for another player to join this room… open this page in a second tab or share the link with the class.
fee 0.0005 · total 0.5005 BTC
live transfers in this room
room ledger · tap a row to replay its steps
- no transfers yet — be the first to pay a classmate.
Conventional database (SQL, CRUD)
accounts
idowneramount
1Alice500
01 INSERT INTO accounts VALUES (1, 'Alice', 500); -- 1 row
One admin, one writable table. History exists only if someone configured audit logs — and the same admin can edit those too.
Blockchain (append-only ledger)
block 1INSERT
Alice = 500
01 tx#1 mined in block 1 · state: Alice = 500
Nothing is overwritten. A "delete" is just another transaction; the old state is permanently auditable by anyone.
Side by side
| Property | Conventional DB | Blockchain |
|---|---|---|
| Operations | Create, Read, Update, Delete | Read and Append only |
| Control | Single admin / organisation | Distributed among participants |
| Trust model | Trust the operator | Verify with cryptography |
| History | Optional audit log, editable | Inherent, tamper-evident |
| Throughput | Tens of thousands tx/s | Single to low-thousands tx/s |
| Cost per write | Near zero | Fees + global replication |
| Best for | Internal apps at scale | Shared state between distrusting parties |
The honest rule of thumb: if one organisation can be trusted to hold the data, a conventional database wins on every metric. Blockchain earns its overhead only when the parties sharing the data do not trust each other.