Even mongo only got a lot of people excited because they had hot girls on the stalls in the conferences. That i think was a master stroke in marketing to nerds. of course later on they improved the product as well, but initially it was a buggy mess and should not have survived the first few years.

The one constant in my career has been mongoDB -- specifically, projects to replace it with a relational database after a deployment had failed to deliver any of the expected benefits, and introduced unforeseen downsides that had become untenable. Mongo has literally never come up in any context for me where it wasn't either already, or eventually, slated for retirement.

I absolutely don't doubt a document store including mongo is an ideal solution for certain specific applications. I just haven't come across one yet personally. For me personally, I would use Postgres for most things and JSONB columns for document-like things until I found a reason to change.

It’s webscale!

Everyone earns the scars from understanding that all data has a schema. If you use pg, you mostly resolve the schema on write; if you use mongodb, you resolve it into a schema on read as well. The latter turns out to be very hard to make robust.

The reason to change is scale. If your Postgres spend is in the six digits a month range, JSONB is probably very painful for you. It does not perform very well. Additionally, you've probably spent a good amount of engineering time painstakingly sharding your database at the application level and hoping you've done it correctly. MongoDB solves these problems out of the box, among others. I have run both of these above 1M a month in spend and I would certainly choose MongoDB for this over Postgres. If you plan on never spending a lot on your database, I do like Postgres a lot, still.

Finally, a correct answer about Mongo, amid a sea of claims from people who clearly know nothing about it.

See, that's exactly why I carefully said I'm sure it exists.

I've personally never had to shard anything in my professional career. Although IDK how painstaking the sharding would really be for most uses I can imagine besides like, social media. Facebook has to deal with everyone interacting with everyone. But the vast majority of situations most developers see isn't like that. You can run Salesforce purely sharding at the tenant level, since I only need to see my tenant's data.

Anyway I feel the need to be emphatic, I'm sure Mongo's benefits can be realized somewhere, just not in any small or medium sized company that doesn't need sharding, and does need a schema.

i worked at MongoDB for nearly 10 years... when the heck did they have booth babes at conferences?