Database Internals · In progress
PageDB
A relational database engine built bottom-up in C23, with a loopback C server and custom binary protocol.
Why I built it
PageDB lets each database abstraction depend on a layer I can inspect. A SQL query eventually becomes page reads and record IDs rather than disappearing behind an existing storage engine.
Architecture
The implementation layers a disk manager, persistent slotted pages, a Clock buffer pool, table heaps, typed tuples and schemas, a catalog, a persistent B+ tree, physical operators, and a bounded parser/binder/planner. A loopback C server exposes the custom binary protocol; the Java client remains future work.
C23 · CMake · B+ tree · buffer pool · SQL · TCP
What the layers forced me to specify
Slotted pages separate record identity from byte movement inside a page. Pin counts and dirty tracking make buffer replacement a correctness problem rather than a cache optimization. The B+ tree persists search structure across pages, and the execution path reads through the same heap and index layers used by storage tests.
What I actually tested
- page serialization and slotted-record mutation
- buffer eviction, pinning, and dirty-page persistence
- multi-page heap scans and record IDs
- B+ tree insertion, lookup, and persistence
- SQL subset execution through the server protocol
Boundary and trade-off
Execution remains single-threaded and single-table. There are no joins, transactions, WAL, or crash recovery, so PageDB does not claim transactional durability.