I find them quite useful. Especially if I've never used technology A. After a while you start to see a pattern of people with similar problems to yours moving away from a certain tech. If it weren't for articles like these, we'd all be making the same silly mistakes over and over again.

Collective hindsight is a powerful thing and we should use it to our advantage to short-circuit certain problems.

If only politics worked that way :/

I was one of the developers on the team that wrote that article. The main point of the article was (and still is) not that PostgreSQL is better than MongoDB, but that PostgreSQL suited us better at that point. In hindsight I think it suited us better because MongoDB was relatively new tech, PostgreSQL was more mature. Especially if it came to tooling and diagnosis on -what- is going wrong when things go wrong, as well as searchable help on the internet.

The extra maturity of PostgreSQL allowed us to learn faster and evolve our software faster with less surprises. As a small team in a start-up this was essential to us.

Considering other articles on that "picked a solution and didn't understand it well" - I do thing they are very valuable.

They provide an insight on how well frameworks and technology support a learning curve. It's not about having only Pro's. it's about how easy it is to get yourself unstuck if you engineered yourself in a corner where you don't want to be.

And I wish they never get old. Every few years, new paradigms come to the forefront and debates like these certainly help many developers choose one way or the other.

In what paradigm are you referring to exactly with Postgres and Mongodb?

Relational turning 51 years old in 2021 while key-value stores category (which MongoDB falls into) is at least 40.

So in a sense this article is about which technology should we use, a 40 or a 50 years old one?

The paradigm of which type of database is best suited for large scale data, distributed in different locations.

MongoDB is not a key-value store. It's a document database.

"Document-oriented databases are inherently a subclass of the key-value store, another NoSQL database concept."

https://en.wikipedia.org/wiki/Document-oriented_database

I've never seen an article about switching from Postgres to something else. Obviously Citus, Timescale, and other Postgres forks don't count.

Uber did one a while ago, but tl;dr they didn't really understand Postgres very well and were dealing with unique problems.

I have seen Uber ping-ponging between Postgres and MySQL. My approach to this problem is, can we use Postgres? If the answer is yes (90% of the cases) we use Postgres. If the answer if no investigate what is good out there. For k:v I have used Riak with much satisfaction. For distributed databases we are experimenting with TiDB. It looks very promising so far.

There is only one problem with Postgres that I run into. Client connection scalability. This is why many users use a connection proxy in the front of it.

I'm not sure they understood the problem they were trying to solve let alone understood Postgres.

here is one from Last year where HSBC bank has moved all its 65 SQL databases into a single MongoDB.

https://diginomica.com/hsbc-moves-65-relational-databases-on...