01 · What you were given
Eight lessons, and they divide evenly in two.
Four handed you a tool
| Lesson | Tool | What it fixes |
|---|---|---|
| 03 · The Dragon’s Gift | Index | Too many pages per query |
| 05 · Divide the Hoard | Partitioning | Too much data per operation |
| 06 · Across Many Keeps | Sharding | Write throughput |
| 07 · Copies of the Ledger | Replication | Read capacity, and survival |
Four taught you to choose between them
| Lesson | What it taught |
|---|---|
| 01 · The Groaning Vault | Measure before you name a cure |
| 02 · Beneath the Vault | Why speed changes at all — pages, memory, eviction |
| 04 · The Dragon’s Debt | What every index costs on the write path |
| 08 · The Price of Many Realms | Which promise you are making, and to whom |
That balance is the lesson. Knowing four techniques is common. Knowing which one a problem calls for is not.
02 · Which one, and when
Never start from the tool. Start from the resource that ran out.
| The symptom | What ran out | Reach for |
|---|---|---|
| Reads slow, low buffer hit ratio | Memory — the working set does not fit | Index first, then partitioning |
| Reads slow, high hit ratio | CPU, or the query’s shape | The query. Storage is not your problem |
| Writes slow, commits queuing | Write throughput — one log, one disk | Drop unused indexes → bigger machine → shard |
| Disk filling up | Storage | Partitioning + retention, then sharding |
| Read volume beyond one machine | Read capacity | Replicas |
| Downtime when a machine dies | Availability | Replication and a tested failover |
| Someone deleted the wrong rows | History | Backups. Replicas cannot help you |
Notice how few rows end in sharding. That is the point of the table.
03 · In what order
Cheapest and most reversible first.
The question is not only will this work. It is what does it cost me if I am wrong.
- Measure. Find the constraint before touching anything.
- Fix the query, add the index it deserves. Most "we need to scale" conversations should end here.
- Drop the indexes nobody uses. Writes stop paying rent on maps no query reads.
- Partition — if the data has a natural boundary your queries already use, and history needs expiring.
- Buy a bigger machine. Badly underrated. Cheaper than the engineering months the next two steps cost.
- Replicate — for read capacity, and for surviving a failure.
- Shard — only when writes are what ran out.
An index is a DROP INDEX away from undone. A partition key means rewriting the table.
A shard means rewriting how your application thinks.
Spend the reversible things freely and the irreversible ones last.
Three ways this goes wrong
- Sharding a read problem. Permanent, expensive, and an index would have done it.
- Adding indexes to fix slow writes. Every index makes writes slower — this one deepens the problem it was meant to solve.
-
Treating replicas as backups. A replica reproduces your
DROP TABLEfaithfully, in milliseconds.
04 · The judgement
Choose the smallest thing that solves the measured limit.
Everything above collapses into that one sentence, and every word in it is load-bearing.
Smallest, because complexity is permanent and capacity is cheap. Solves, because a tool aimed at the wrong constraint is not a partial fix — it is a second problem stacked on the first. Measured, because without evidence you are choosing by instinct, and instinct reaches for whatever you read about most recently.
Three questions, asked out loud, before any of it:
- What ran out? Name the resource, with a number attached.
- What is the cheapest thing that fixes it? Start at the top of the ladder.
- What will this cost me forever? Some doors do not open again.
You will not always get it right. But a keeper who can say which resource ran out and why this tool addresses it is already doing what most never do — and can defend the answer when someone asks.
The Old Dragon “Go now, keeper. And when they ask you how to scale it, ask them what has run out — and watch how few of them know.”