Build a Database from Zero: Series Guide

Most database tutorials tell you how a database works. This one makes you build one.

Instead of memorizing "B+ trees make indexes fast," you'll build an array, watch it get slow, build a hash table, watch it fail at range queries, build a B+ tree, and finally glue everything into a small but honest database you actually wrote.

Every concept arrives because you need it, not because a syllabus says so. By the end, the things most people only memorize — why Seq Scan is expensive, why the second query is faster, why indexes work, why some tables can go without a primary key — are things you derived.

• Front-end developers who already use localStorage / JSON and write JS / TS;
• People who know a little SQL but feel the database is a black box;
• Anyone who'd rather understand than recite.

Build a database that holds rows in pages, finds them by an index, and caches them in memory. Not a production system — the skeleton of one.

The series follows one thread: data in memory → data on disk → how it's found and made fast.

Part 1 — An array of JSON is also a database. A table is just typed rows; a query is a loop. Watch a sequential scan go slow; feel O(n) for yourself.

Part 2 — Turn "how to query" into "what you want." Split the hardcoded loop into a declaration + an engine. See why decoupling "what" from "how" is the precondition for all optimization.

Part 3 — Too slow? Build a hash table. Feel a real O(1) key lookup, handle collisions with chaining and load factor — and discover its limit: it can't do ranges.

Part 4 — Get sorted, build binary search. Ranges now work — but inserting must shift everything. That pain is what forces you toward a tree.

Part 5 — The B+ tree, the index real databases use. Build a BST up to a B+ tree: keys in internal nodes, data in linked leaves, both find and insert cheap.

Part 6 — An index stores addresses, not data. Invent the TID (a row's address), see heap-table vs index-organized-table, and derive the answer to "why can PostgreSQL have no primary key?"

Part 7 — Get data onto the disk. Learn why writing the whole table to one file is a disaster, and why a database breaks the file into pages.

Part 8 — A page: read by chunk, not by row. See a page's directory, understand seek latency, and work out why page size (8KB) matters.

Part 9 — The buffer pool. Cache pages in memory, evict with LRU — and explain "the second query is faster." Tie it to reason out why Seq Scan costs so much.

Part 10 — The whole machine and the answer to "no primary key." Glue disk → page → index → buffer pool into one honest database; final answer, by construction.

• Explain, with your own hands, why Seq Scan is expensive (it's the number of pages);
• Build a hash table, a binary search, and a B+ tree from scratch and explain the tradeoffs each one makes;
• Explain why the second query is faster (the buffer pool) and how eviction works;
• Explain why PostgreSQL can have no primary key but InnoDB can't — as a storage-engine fact, not a memorized one;
• Recognize the skeleton of every real database (PostgreSQL, MySQL) inside the toy you just built.

You deliberately left out of a toy the parts that only matter at scale and under concurrency. The "understanding databases" series continues with: transactions and ACID, isolation levels and MVCC, locks and deadlocks, ORMs and the N+1 problem, connection pools, and EXPLAIN in practice. The storage layer you built here is the foundation all of those sit on.