Forem: NodeDB

What Kind of Database I Want NodeDB to Be

Farhan Syah — Fri, 03 Apr 2026 08:19:35 +0000

When I think about NodeDB, I am not thinking about the longest feature list or the flashiest demo.

I am thinking about a database I can trust before and after an application grows.

In the long run, I want NodeDB to be easy to use, reliable in different scenarios, and secure enough that I do not have to keep second-guessing it. I want it to be something I can start with early, keep using later, and not feel forced to replace once the project becomes more serious.

I should not have to rethink the whole stack every time product requirements change. I should not have to move data somewhere else just because a new use case shows up. I should not have to accept that one part of the database is “real” while another important part is just a workaround. If the business grows, the database should still feel like a stable base, not the next reason to re-architect.

But that is far in the future. The current reality is simpler: I am still building toward it.

Right now, my main concern is not polish. It is not making NodeDB look finished before it is finished. It is the foundation.

I want to build enough core capability early, and build it deeply enough, that I do not spend the next few years patching around missing pieces.

Many databases grow by accumulation. A feature becomes important, so it gets added. Another workload appears, so another layer gets introduced. Then another extension, another plugin, another wrapper, another sidecar. Over time, the system may cover more ground, but it does not always become more coherent.

From the user side, that has a cost. Query behavior becomes uneven. Operational expectations stop being consistent. One feature feels mature, another feels awkward, another works only if you accept a few strange rules. At that point, you are not really using one clean system anymore. You are managing the boundaries between several pieces that happen to live near each other.

That is one of the reasons PostgreSQL started feeling heavy for me across multiple projects.

PostgreSQL is good. Its ecosystem is strong. I am not arguing otherwise. But extensions do not magically become one deeply integrated system just because they run around the same database core. In practice, the burden shifts to the user. You are the one stitching capabilities together, working around different limitations, and dealing with the gaps between them.

I have seen a similar pattern in databases that try to unify more from the start.

SurrealDB has a vision I understand. But my concern is the same: I do not want a database to keep piling things on top if the foundation was not designed to carry them well. Systems should evolve, of course. That is normal. But there is still a difference between growing a system and collecting features.

That difference shows up in the user experience very quickly. Some capabilities exist, but they still feel second-class. The ergonomics are weaker. The query model is thinner. Performance is less predictable. Operations feel awkward. The feature works in a demo, but once it becomes central to a real workload, you start seeing the limits.

That is exactly what I want to avoid with NodeDB.

I want NodeDB to reduce re-architecture later instead of causing it. I do not want to reach the next stage of a product and realize that an important capability was treated as an afterthought, so now the stack has to be rearranged. I do not want core requirements to arrive later and collide with a design that was never meant to support them properly.

That is why I care so much about feature depth early.

Not because users need everything on day one. And not because I think I can build everything perfectly from the start. I cannot.

What I do believe is this: if an important capability is likely to matter sooner or later, I would rather think hard about how it belongs in the system early.

I am not interested in a product page that lists many features. I care about whether the database actually behaves like one cohesive system. I care about whether the features feel like they belong together. I care about whether it stays usable across different scenarios without pushing the user into constant redesign or workaround.

If a database claims to do everything, but half the capabilities feel weak, awkward, or fragile, that is not real completeness. I would rather build something deeper but longer than wider and shallower.

So the database needs to be dependable. It has to hold up when requirements expand. It has to help the user avoid unnecessary stack changes later.

Maybe this approach is wrong in some places. It is still my opinion, my bias, and my way of thinking through the problem.

But if NodeDB works, I want it to work in a way that still makes sense years later, not just in the first exciting demo.

In the next post, I will go deeper into the design direction behind that idea and why so many multi-model databases still feel wrong to me.

Repo: NodeDB

Why I'm Building NodeDB

Farhan Syah — Thu, 02 Apr 2026 21:26:16 +0000

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