| Here's my theory on MongoDB, having spent a lot of time thinking about it: There is going to be some huge number of new developers every year for the foreseeable future, and Mongo is the lowest barrier to entry database available. These people don't know SQL and don't care that "Postgres is better". Mongo does a few useful things really well, and everything else (like sharding) is a moat around that core value proposition, which is why Mongo gets away with being bad at a lot of stuff. Mongo is good at: * Starting up (when you download it, you literally just get a mongod binary). * Inserting JSON documents. * Indexing those JSON documents. * Composing queries programmatically (because they're JSON documents). * Replication (oddly). Mongo is bad at: * Analytical queries. I've literally written a book about Mongo and still can't remember most query syntax. * Efficient data storage - documents take a huge amount of space. * Scaling. * Sharding - this feature has always been half-baked. * A lot of other stuff. Your immediate inclination is probably to say something like "but look at (Couchbase|MySQL|Cassandra|Rethink|Postgres), its so much better written and it does (document storage|relational querying|scaling|sharding|json documents now in version 9.4!!!!!) so much better". Again, thats not the point, the lesson here is that MongoDB is a thing because barrier to entry is a better feature for many users. |
What's funny is that on all but one of your "Mongo is good at" points, Solr beats the snot out of it. The only debatable one is ease of starting up, which is a silly criterion when talking about a project that has any sort of lifespan. Even then, Solr startup is really quite easy.
Obviously Solr uses special-purpose indexing that one might argue is a bad fit in some cases but if you're using Mongo anyway...
Postgres is good but its horizontal scaling "story" is not great, obviously. But finding the edges of Postgres's goodness will take much longer than to bump into Mongo's limitations.