For the last few years, PostgreSQL has been my default database.
Before that, I worked with MySQL, MariaDB, and MongoDB. But once I spent enough time with PostgreSQL, it became very hard to justify anything else for most projects. It gave me the relational model I wanted, plus JSON support that was good enough to remove a lot of my reasons for using MongoDB. When I needed spatial support, I could add PostGIS. When I needed time series and partitioning, I could use TimescaleDB. For a long time, that worked very well.
Then the workload started changing.
Over the last two years, AI and ML stopped being side concerns and started becoming part of real application requirements. That meant vector search became relevant. PostgreSQL still looked like the right answer because pgvector existed and, at first, it was good enough. But once I started using it across more serious workloads, I kept running into the same friction: scaling and performance concerns, filtering limitations, and dimension and storage constraints that mattered for my use cases at the time.
And vector was only one part of the problem.
Then came graph needs. At that point, the pattern became very familiar. I could keep stretching PostgreSQL. I could handle graph logic manually at the application level. I could try more extensions. I could wire more tools together. And yes, any one of those decisions can be justified if you are working on one project and you are willing to absorb the complexity.
But I am not working on one project.
I work on multiple projects every year, often with different requirements. That changes the economics completely. What looks reasonable in isolation turns into repeated operational and mental overhead when you keep doing it again and again. A couple of extensions are fine. Then you need another one. Then another workaround. Then another set of limitations, quirks, and edge cases to remember. Then offline-first and sync requirements enter the picture and now you are adding even more surrounding tools just to make the whole thing usable.
That was the real breaking point for me.
The problem was not that PostgreSQL stopped being good. The problem was that PostgreSQL plus extensions plus surrounding infrastructure started becoming a stack I had to keep rebuilding across projects. It worked, but the repetition was exhausting.
I started looking around.
Like many people in this space, I first looked at what already existed. If someone had already built the thing I wanted, I would rather use it than build a database from scratch.
I found SurrealDB. I liked the vision. I still think the direction is compelling: fewer hops, better developer experience, a more unified model. But when I looked deeper, especially at the implementation and tradeoffs, I was not convinced. From my perspective, it felt more like a patchwork than a database designed deeply from the ground up. Even in graph support, I did not find the level of capability I expected. The idea was attractive. The execution did not give me enough confidence.
Then I looked at ArcadeDB. In many ways, I thought it was stronger. Better coding quality, better performance characteristics, more substance. But it is JVM-based, and I wanted something smaller, tighter, and better suited to the kinds of embedded, mobile, offline-first, and mixed deployment scenarios I care about.
At that point, my realistic options looked like this:
Stick with PostgreSQL and keep stacking extensions. Work around another database that did not fully fit. Or accept a polyglot architecture and keep paying the integration cost.
None of those felt right to me.
So I chose a fourth option: build my own database.
That is how NodeDB started in 2025.
It started as a side project, and honestly, I did not have high expectations. If it worked, it worked. If it failed, it failed. That attitude was useful because this is not the kind of project you begin with false confidence.
I have already scrapped the project twice.
This current version is the third serious attempt, and I only started building it earlier this year. The first two failures were important. They forced me to understand what I was doing wrong, what I was hand-waving, and what needed to be designed properly from the beginning instead of patched later. I do not think I would have reached this version without those failures.
One thing I should mention briefly: I use AI heavily in the implementation.
The code is mostly written by AI, not by me typing everything manually. That is simply the practical reality. It writes faster than I do, and often better than I do at raw throughput. But I am still the one directing, reviewing, rejecting, and understanding it. That part matters to me. If I am going to build a database seriously and support it in the future, I need to understand it all the way down.
NodeDB exists because I wanted something I could actually use across real projects without rebuilding the same database stack every time.
I built it first to solve my own use cases, because that part is non-negotiable. If it does not solve my real problems, there is no point. But I also do not want to build a shallow personal tool that only works for me. I want to go deeper than that. I want something that can support broader use cases properly, with serious performance, serious design, and serious technical depth.
Right now, NodeDB is working for my use cases, but it is still evolving.
I have already tested it in pilot projects, and for the kinds of problems I built it to solve, it is starting to prove itself. That does not mean the journey is done. Far from it. A database only becomes real when the design holds under pressure, when the tradeoffs are honest, and when the implementation can stand up over time.
That is the challenge I have chosen.
Will I make it? Time will tell.
But this is the journey I am on, and I am going to share it openly: the design decisions, the mistakes, the database ideas, the tradeoffs, and the lessons I learn along the way.
If you care about database engineering, multi-model systems, offline-first architecture, or the hard tradeoffs behind building a database from scratch, follow this journey.
I will be sharing what works, what fails, what I have to redesign, and what I learn from trying to make NodeDB real.
If that sounds interesting, follow me here on dev.to and keep an eye on the next posts. I am just getting started.
Repo: NodeDB
Top comments (0)