A tutorial on nan.fyi turns the idea of a database into a set of practical engineering tradeoffs. Rather than starting from a finished system, the guide asks how you would build a key-value store if you had to create one from scratch. The answer unfolds in stages: persist data to a file, make updates append-only, add tombstones for deletes, then introduce compaction and indexing to make the system usable.
The first lesson is that simple persistence is easy to imagine but inefficient in practice. If records are written one after another and searched by scanning the whole file, inserts are straightforward, but updates and deletes quickly become expensive. A change to one record can force later bytes to move, which makes in-place editing impractical once the file grows.
The guide’s next move is to treat records as immutable. Instead of rewriting old entries, the database appends a new version to the end of the file. Deletes are represented with a special marker that signals the key has been removed. That approach solves the rewrite problem but creates another one: stale data accumulates, and the file grows with duplicate or invalid entries.
Compaction is the answer. When a file reaches a threshold, the system can stop writing to it, create a new segment, and clean the old one by discarding outdated records. This is a familiar storage pattern because it lets the database keep ingesting new data while gradually shrinking away dead weight. The guide also notes that segments can later be merged, which makes the overall store manageable as it scales.
Searching presents a different bottleneck. Scanning the whole file for every lookup is too slow, so the tutorial introduces an in-memory hash table that maps keys to byte offsets in the file. That makes reads much faster, but it also reveals a tradeoff: the index must stay synchronized with every insert, update, and delete. Faster search comes with slower writes and extra bookkeeping.
From there, the post begins to move toward sorted storage and range queries, showing that a database can evolve by layering structures rather than replacing them all at once. One of the useful aspects of the guide is that it treats each improvement as a response to a specific failure mode. Append-only storage fixes one class of problem, indexing fixes another, compaction handles file growth, and sorting opens the door to more efficient querying.
The result is an accessible tour of the mechanics that often remain hidden behind a database interface. It does not pretend that a file plus a hash table is production-ready. Instead, it demonstrates why real storage engines are shaped by a sequence of compromises between durability, write speed, read speed, and maintenance.
For readers who only use databases through higher-level software, the article is a reminder that every simple `get` or `put` rests on a stack of tradeoffs. The point is not merely to build a toy database. It is to see why mature systems look the way they do, and why the path from a flat file to a reliable store usually runs through append-only logs, tombstones, indexes, and compaction.
