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
Top comments (0)