QueryForge: A SQL Database Engine Built From ScratchQueryForge

Most "database demos" are a thin UI over Postgres. In QueryForge the database is the project. Rows live in 4 KB pages, the index is a B+tree where every node is a page, and durability comes from a write-ahead log, built in layers that can each be tested alone. The main feature is that you can see it happen: type SQL and the tokenizer, parser, planner, B+tree and pages animate in order, replayed from the engine's own event log.

The engine is pure TypeScript with zero DOM dependencies, so the same code runs in the Vitest suite and in the browser tab. A tracer threads through the pager, B+tree and executor, and the playground is a replay of that event log, so the visualization cannot drift from what the engine did. fast-check property tests cover the parts where correctness is subtle (10,000 random inserts, every lookup correct, every leaf at the same depth) and shrank the split bug to a four-key counterexample in seconds. The fix was one line: zero the node body before re-serializing.

QueryForge runs entirely client-side. You type a query, watch the plan light up, then flip "force full scan" and see the difference in the row-visit counter. Pull the plug to wipe memory, hit Recover, and the WAL rebuilds every page on screen. Building it is how I came to understand what a database does underneath a query.

“

The WAL is logical and replays from the start of history with no checkpoints. That is fine for a teaching engine and painful at scale, so checkpointing is first on the list. I left out DELETE/UPDATE, transactions and JOINs on purpose. The Volcano iterator model already fits a nested-loop-then-hash join, so joins are the next step and would not need a rewrite.