Second that, i’ve built multiple services with MongoDB just to port them now (and probably for some time) to postgres.

That only makes sense if you wanted to store relational data in a NoSQL database (and that's not what Mongo is meant to do)

I'm genuinely curious what you mean when you say "relational data"? I've seen this phrase thrown around and I think it's something of a misconception.

The way you use the term implies that you're referring to the type of data, but the term generally refers to the method used for storing the data.

This distinction is important because it leads to a circular reasoning dynamic: many of us are accustomed to storing the data in tabular form using a relational data model. But choosing to use that particular model to represent objects or entities or ideas does not make those objects or entities or ideas fundamentally relational data.

Is that really true these days? Setting up Postgres read replicas with automatic fail over across multiple machines is pretty trivial in the cloud with services like RDS, spanner etc. And although doing it in your own datacenter is still a big job it's far from impossible.

Huh? Replicas are easy, and hot standby nodes aren’t that hard either. There are also various active-active solutions if you need that.

Just curious why? I have never worked with NoSQL but I always envy the people who does that because they are a bit further away from business than us data warehouse modellers. They are usually our upstream, paid more and less hassle from business.

Postgres and NoSQL are not exclusive, Postgres works pretty well as NoSQL (some would say better than Mongo).

This is an extremely misleading statement. You have to jump through hoops to do expressive queries, with a limited set of index primitives, a query optimizer that doesn't take advantage of anything that resembles nested JSONB, and syntax and storage overhead that will leave you thinking there's nothing good about storing data with rich JSONic structure begin with.. worst of all worlds

I used it for that and it is not like a hell you describe.

What kind of scale are we talking to out of curiosity?

Pretty small.

And yet almost all of the major websites you use today rely on NoSQL.

Also if you have non-traditional data structures e.g. document, star, graph, time series then storing them in a SQL database will cause you nothing but problems.

There are no black/white answers in tech. Always right tool for the right job.

> And yet almost all of the major websites you use today rely on NoSQL.

They may use NoSQL in specific use cases, but certainly not exclusively. Using the right tool for the job is crucial; otherwise, you’re doing yourself and your product a disservice.

In this case, NoSQL database architecture and internals provide little to no advantage over relational databases. I can’t imagine building a calendar implementation with NoSQL. Some flexible parts of the event model might be stored as NoSQL, but in general? No way.

Edit: looks like I wrote my comment as you were editing yours. We agree :-)

It's a weird argument because the article is wrong.

Google Calendar is not implemented on top of a traditional SQL database but rather on top of Spanner which is more akin to a NoSQL database with a SQL front end.