Gravity for Databases
Every database you've ever used — MySQL, Postgres, Cassandra, DynamoDB — is ultimately just a program that reads and writes bytes to a storage device. The laws of physics don't care about your SQL queries. They only care about one thing: how the bytes are arranged on disk.
Two physical facts govern everything in this topic:
- Sequential I/O is fast. Reading 1 MB of data stored in one contiguous block on disk is like streaming a movie — the disk head moves in one direction and data flows continuously. Modern NVMe SSDs can do this at 5–7 GB/s.
- Random I/O is slow. Reading 1 MB of data scattered across 256 different 4 KB locations is like skipping around a movie to find 256 specific frames. Even on NVMe SSDs, random I/O is 10–100x slower than sequential I/O because each read requires a separate command round-trip to the device controller.
Every database storage engine is an opinionated strategy for organizing data on disk to exploit sequential I/O as much as possible — for either reads or writes. You rarely get both simultaneously.
There are two dominant architectures that power the vast majority of modern databases:
- B-Trees — The general-purpose workhorse. Used by MySQL (InnoDB), PostgreSQL, Oracle, SQL Server, and SQLite.
- LSM Trees (Log-Structured Merge-Trees) — The write specialist. Used by Cassandra, RocksDB, LevelDB, ScyllaDB, and DynamoDB's underlying storage.
Understanding the mechanical differences between these two is not academic trivia. It directly determines which database you choose, how you tune it, and why it fails under specific workloads.