Why Document or NoSQL Databases?

I'm working on a project at the moment and was wondering which DB to use. So I did a bit of research. I had wanted to use a Document based DB, mostly because:

1. I can find a lot of free hosting options which will more than exceed my needs
2. They often don't require an ORM which simplifies things

The end result? I'm probably going with Postgres. For the uninitiated, that is NOT a Document or NoSQL DB.

In the process I stumbled across this article from Mongo DB. What I like about it is that it does at least contend that there is a place for Relational Databases. The article is, of course, heavily biased toward Non-Relational Databases (as that is exactly what Mondo DB is). Though, I also found it interesting that it effectively conceded some reasons as to why things are in the state that they are. And that it has nothing to do, inherently, with Relational vs. Non-Relational.

That point was that Relational databases simply weren't built with the sort of scale in mind that the modern web frequently demands and most Non-Relational databases were.

Which is to say, there is no INHERENT reason why a Document database should be quicker or better in any quantitative way when compared to a traditional relational database. It is simply that this kind of evolution isn't in their DNA and they can't overcome it.

This is the part where I diverge and circle back to my ongoing diatribe; don't pigeon-hole yourself in a single design decision or architecture. THIS is why I say to not commit 100% to either microservices or monoliths. To consider using multiple DB backends. To use micro UIs with different frameworks.

These all seem like wasteful endeavors up front. But they all pay off with dividends down the road. Having built a microservice or two aside a monolith you will know how to deal with inter-service communication, more complex deployments and a host of other challenges. But, having built a part or parts as a monolith you'll know when the performance gains scale and when they don't.

By working with multiple DBs you'll start to learn which ones are better suited to which tasks and likely how to migrate your data safely between storage solutions eventually.

No UI framework has ever stood the test of time. Every major framework either ceases development or starts making breaking changes forcing you down a road where you need to consider the effort to move to something else. Most of the times this means 2 things:

1. Committing to rewriting the entire app
2. The need to evaluate one or more entirely new frameworks

Having a Micro-UI strategy though, you can simply reroute one screen at a time to a new Platform. You also have more than Framework under your belt from the start. And a lot less stress if you need to consider a new one.

Relational databases never considered the scale. They probably can be made to scale. FerretDB is an interesting little project which illustrates this. It basically makes Postgres a distributed database and then slaps a Mongo DB compatible interface in front of it. The team behind Postgres could likely do something like this, and probably do it better. But, for them, they don't have the experience or the appetite to diverge from what they've already committed to.

Likewise a new Non-Relational DB could easily be built without supporting the sort of scaling which makes solutions like Mongo and CouchDB so successful for super massive databases.

I would also say that Mongo's article is rather intentionally vague about the sorts of database sizes at which SQL becomes less powerful and able. Though it is admittedly much more hardware dependent it is pretty safe to say that many companies successfully operate Postgres, Oracle and SQL Databases into the realm of several gigabytes without issue.

I would also say that this is MUCH larger than what most companies NEED. Unless you collection millions of points of data daily and/or having millions of active users you're probably not anywhere near the realm of needing a super computer to keep your relational database running at top speed.