The Log-Structured Merge-Tree (LSM-Tree)

Why this one

This paper is the reason your write-heavy database is fast, and it predates every system you associate with it - RocksDB, Cassandra, LevelDB, ClickHouse's parts, the storage layer under half of the NoSQL world. The argument is about disks: random writes are expensive and sequential writes are cheap, so buffer everything in memory, flush it as a sorted run, and pay the sorting cost later in background merges instead of on the write path. Read it with the B-tree lesson beside you, because the whole thing is one trade - LSM moves cost from writes to reads and to background compaction; a B-tree does the reverse. Once that trade is in your head, choosing a storage engine stops being a matter of taste.