I am a first-year CS student and I recently made a decision that most people around me think is unnecessary — I am building a relational database storage engine from scratch in raw C++, with zero STL dependency.
No std::vector. No std::string. No iostream. Nothing.
Here is why.
The Problem With How I Was Learning
For a long time I was writing code that worked but I had no idea why it worked. I used abstractions, APIs, and libraries that hid everything interesting. I could build things but I couldn't explain what was actually happening in memory, on disk, or at the hardware level.
That bothered me.
What NanoDB Actually Is
NanoDB is my attempt to fix that. It is a custom storage engine I am building in phases:
Phase 0 — Raw C++ fundamentals, no safety nets
Phase 1 — Page Manager, raw disk I/O
Phase 2 — Buffer Pool with LRU eviction
Phase 3 — Heap File and Tuple layout
Phase 4 — B+ Tree Index
Phase 5 — Query Layer
Phase 6 — Write Ahead Log
Phase 7 — Concurrency with 2PL
Phase 8 — Benchmarking and research documentation
I am currently at Phase 0. I am not going to pretend I am further along than I am.
Why Ban the STL?
Because the STL solves problems I haven't suffered through yet. If I use std::vector before I understand dynamic memory allocation, I learn nothing about what std::vector actually does. The restriction forces me to feel the pain that the abstractions were hiding.
That pain is the education.
Why Am I Writing This Now, Before Writing Code?
Accountability. And because the "why" matters as much as the "what."
I will be documenting every phase here — what I built, what broke, what I learned, and what confused me. No polished success stories. Just the ugly process.
If you are also exploring systems programming or low level C++, follow along. We can figure this out together.
Phase 0 starts now. ⚔️
Top comments (0)