Don’t use it for relational data. Don’t use it as your primary data store.

At the enterprise I work at, I’ve had success delivering features where data science would have some job that aggregates production data and dumps it to kafka. Then we’ll map it and dump it in mongo. Stick a .net core microservice on top for retrieval. Works great, has none of the problems mentioned in that article. Of course, this might not make sense if you’re not big enough to where you need kafka, kubernetes, etc

But “Never use it” is certainly not good advice.

How can you know if your decision is correct if you never use it in the first place. Isn't it like only implementing A version of A/B and concluding that not implementing B version was a good decision.

> What’s missing from MongoDB is a SQL-style join operation, which is the ability to write one query that mashes together the activity stream and all the users that the stream references. Because MongoDB doesn’t have this ability, you end up manually doing that mashup in your application code, instead.

Even with a normalized relational database one wouldn't make a single query to return rows from a join of tables T1, T2, T3, etc when there are repeating relations such as the users in the social graph. This might be done sometimes paying for the duplication to save a network round trip, that's all and no different.