Build AtlasDB
Not a database product — a way to understand one. atlas.db starts as a flat file and grows one mechanism at a time. Every version exists because the previous version broke under a specific load; read the “problem” first, then the change, then why it will not be enough.
- V0Flat File→
- V1Records→
- V2Pages→
- V3Slotted Pages→
- V4Index→
- V5B+ Tree→
- V6Buffer Pool→
- V7Write-Ahead Log→
- V8Transactions→
- V9MVCC→
- V10Query Engine→
- V11Replication
V0 Flat File
atlas.db is one file; every write appends a line, every read scans it.
atlas.db ──────────────────────────── 1,alice,alice@example.com 2,bob,bob@example.com 3,carol,carol@example.com …
- There is no database yet — only data that must outlive the process. A file is the smallest thing that survives a restart.
- A text file. `INSERT` appends a line; `SELECT … WHERE id = 3` reads from the top until it finds the line.
- Everything is a byte sequence: the schema is implicit in the column order.
- Reading is O(file). A 10 GB file means 10 GB of reads for one row.
- An update rewrites the whole file; a crash mid-rewrite loses everything.
- Nothing says where one row ends and the next begins except a newline you hope no value contains.
Every database begins as bytes in files. PostgreSQL keeps one file per table segment under `base/<dboid>/`; SQLite keeps the whole database in one file.
From table to SSD: the storage hierarchy
The simulator for this version. Numbers are modelled for teaching, not measured from a real engine.
The fixed-size unit the engine reads, writes, caches and locks. A page has a header (checksum, free-space pointers), a slot directory and the records. A record is addressed as (page number, slot).
Buffers: shared hit=…), a checkpoint writes pages, a lock protects a page. Reading one 77-byte record costs the same 8192-byte read as reading all hundred on the page.