I think there are two separate aspects that get conflated into one. 1) Document database - rather than a strict rigid schema, you can store nested json documen

I think there are two separate aspects that get conflated into one. 1) Document database - rather than a strict rigid schema, you can store nested json documents in tables/collections. Or the idea of soft schema where the whole database doesn't need to be blocked for a schema change and you have some leeway in integrity. 2) Relational database - Ability to make complex sql queries that join data from multiple tables. Mongodb has some support for joining but it doesn't have a sql variant. If your data is mostly key:val store then it's great. You can shard it, and have replicas. It's easy to make a fast reliable backend with mongodb. Many popular sites run on mongodb backend. However with new json types in MySQL and Postgres, it too has support for inserting documents and querying subkeys. It can be sharded and replicated (albeit with a bit more configuration). Couchbase which is like mongo (in its document store capabilities) N1QL which offers agility of SQL and flexibility of JSON. So like any tool, it has it's tradeoffs. Then again kudus to the author for evoking our reptillian brains: "Never use MongoDB" incites emotions and gets you on top of HN. If it was called "When to use MongoDB", it wouldn't get the same reaction.