About the builder
I'm Charan. I build intelligent systems — and occasionally the unglamorous machinery underneath them.
I'm an AI & Automation Engineer in Bangalore. Most days I ship production LLM systems — a Springer-published model that reads chest X-rays well enough for a radiologist to take seriously, document pipelines that run themselves. Before all that, I wrote real-time control code for jet engines at DRDO, where a millisecond of lag isn't a bug — it's a flameout.
So why spend nights building a database from scratch? Because I got tired of treating the thing under the ORM as a magic box. QueryForge is me opening the box: a real storage engine, a real write-ahead log, a real query planner — and a playground that shows you the B+tree splitting and the crash recovery as they happen. No Postgres underneath. No mocks. If the engine didn't do it, you don't see it.
This is one project. There are 18 more (and a few jet engines) over at charanreddy.dev.
What I learned building this
Five things, honestly. No filler.
A balanced tree is an invariant, not a vibe
I thought I understood B+trees until I had to make splits propagate correctly to the root. The property tests — 10,000 random inserts, every leaf must end at the same depth — found bugs my hand-written examples never would.
Durability is just discipline about ordering
The whole magic of a write-ahead log is one rule: log the intent before you touch the data. Once I built the 'pull the plug' button and watched recovery rebuild every page from the log, the concept stopped being a paragraph in a textbook.
The planner is where databases get their reputation
Parsing and execution are mechanical. The interesting decision is whether to walk a B+tree or scan the whole heap — and being able to toggle that live, and watch the row-visit counter jump, made the cost of a missing index something you can feel.
Keeping the core DOM-free paid for itself
The exact same engine code runs in the Node test suite and in your browser tab. No mocks in the playground — the animation is literally replaying the engine's own event log. That constraint forced cleaner seams everywhere.
Explaining it well is half the work
I could have shipped a correct engine in a black box. Making the internals legible — the search path lighting up, pages flipping as they're written — took as long as the engine itself, and it's the part people actually remember.
Curious how it was built?
The timeline, the hard parts, the tradeoffs.
Have an idea? Let's talk.
Want to build something — or break something interesting? I'm around.