Paged storage engine with slotted pages, a buffer pool, B+ tree indexes, write-ahead logging and crash recovery — then a parse → plan → execute query path on top.
Durability and isolation are easy to use and hard to explain. I wrote a storage engine from the page layout up so that the reasons behind WAL ordering, buffer pool eviction and B+ tree splits came from my own bugs rather than from a diagram.
Me, as a backend engineer
Understand what an fsync, an index choice and an isolation level actually cost underneath.
Anyone reading the code
A small engine where the whole path from SQL text to page write is readable in one sitting.
Fixed-size pages with a header, a slot directory growing from the front and tuple data growing from the back. Variable-length rows fit without rewriting the page, and deletes leave a reusable slot — the layout that makes everything above it possible.
A fixed set of frames with pin counts, dirty flags and an eviction policy. Nothing pinned can be evicted; a dirty victim is flushed first, and always after its log records. This is where the WAL rule becomes concrete rather than theoretical.
Keys in internal nodes for routing, values in leaves, leaves chained for range scans. Splits propagate upward and can grow a new root. Getting split and redistribution correct under a page-sized node was the part that took the longest.
Every page modification appends a log record, and the log is flushed before the page write. Commit is a log record reaching disk — not the data page. That ordering is the entire durability guarantee.
Recovery scans the log, redoes committed transactions and undoes uncommitted ones. I tested it by killing the process mid-write, repeatedly, at different points — which is how I found the ordering bugs that a clean shutdown never exposes.
A tokenizer and recursive-descent parser produce an AST, a planner picks between a sequential scan and an index scan, and an operator tree executes it. Small, but complete from SQL text to page write.