Build a B-tree storage engine (SQLite-style)

You wrote INSERT INTO users(id, name) VALUES (42, 'Alice'). SQLite acked. Where did the row go?

You probably know it ended up in users.db somewhere. You may have heard the words "B-tree" and "WAL." You probably don't know — yet — that users.db is one file divided into 4 KB pages; that every read or write touches a whole page; that your users table is a B-tree of those pages with hundreds of children per interior page; that your INSERT walked from the root down through three pages to find its home leaf, wrote one cell, and (if you were lucky) came back without having to split anything; that the row didn't actually mutate users.db — it appended a frame to users.db-wal and fsynced that file; that the main file will catch up "later" (a checkpoint); that if a long-lived reader is open, that "later" never comes and your WAL grows to 20 GB.

This curriculum builds that picture, in order, from a SQL writer's perspective. Each scene starts with the question your last scene left unanswered, shows the next mechanism in a diagram you can drive with a slider, asks you to predict a consequence, and captures a one-line answer. By the end you can size a SQLite deployment for write-heavy logging, read-heavy reference data, or OLTP — and trace every knob's failure mode back to the scene that explains it.

The point is not to "describe SQLite." The point is to feel why a database is the shape it is. Once you've built this picture, every subsequent storage engine — InnoDB, Postgres heap, RocksDB, FoundationDB — collapses to "B-tree with this knob different" or "the LSM answer to this exact problem."