Planetscale’s primer walks you through B‑trees, indexes and why UUID primary keys can sting

Ben Dicken’s new Planetscale post unpacks the humble B‑tree — the behind‑the‑scenes workhorse of MySQL, Postgres, MongoDB and many other databases — and makes a case for why it still matters in 2024. The piece is part explainer, part interactive lab: you can click through animations to watch nodes split and merge, and see why tree shape matters for real‑world disk performance. It’s accessible, practical, and yes — it even tells you why randomly chosen UUID primary keys might not be the neat trick you hoped for.

What is a B‑tree?

Think of a B‑tree as a very organized root system. Each node holds a set number of ordered key/value pairs and pointers to children; every leaf sits on the same level; and you only need to visit one node per level when searching. Dicken walks through the formal constraints — order K, node capacities, child pointers — then shows how that enforced ordering yields fast lookups. Short hops, fewer levels, fewer disk reads. Simple idea, big payoff.

Why databases love B‑trees

The real magic? B‑trees map nicely onto disk blocks. Nodes can be sized to match 4k/8k/16k blocks so a single disk read pulls in a chunk of index that’s actually useful. That’s why B‑trees are the default index structure in many DBMSs: they minimize slow I/O by turning many tiny reads into a few big ones. Dicken also contrasts B‑trees and B+trees, and teases how insertion patterns — say, inserting random UUIDs — affect tree shape and, therefore, performance.

Which leaves the emotional bit: you want fast lookups, but you also want sane keys. UUIDs feel modern and convenient. But do they cost you depth, fragmentation and extra I/O? Dicken’s write‑up nudges you to think twice, experiment with the provided animations, and match your key strategy to your workload — because in databases, as in life, the small design choices add up.

Sources: planetscale.com, Hacker News