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.
* 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.
MS Access is a higher barrier of entry to a developer who knows some other language but not SQL and just wants to throw on a datastore than MongoDB is.
It might be a lower barrier to entry to learn Access from the beginning than (programming language) + (MongoDB) -- though I'm somewhat dubious of even that.
That said, it's got a really nice query API and is quite simple to get up and running for hackathons or simple home projects. It's got a decent map/reduce story for simple tasks, and overall I don't really see anything wrong with it.
There's just a lot of backlash because some earlier versions did dumb things by default (which were fixable if you consulted the docs), because Postgres can do almost all of the storage things Mongo does and faster (once finally setup and tuned, and if you don't mind losing that nice API [unless you want to set things up with Mongres or similar hacks]), and lastly that all of the cool kids on HN were congratulating each other on how awesome Mongo was and just in general being annoying.
That's it, really.
To misquote Tyler Durden: "You're not your fucking tech stack." Especially when you are working on something that is more of a business problem than anything else.
That is such an awesome quote, I want to print a picture of brad pitt from Fight Club and put that as caption.
I think the last time I used MongoDB was when I was fiddling around with Meteor.js
I recall struggling with CRUD queries using MongoDB and pretty much gave up after that.
I've been using MongoDB for many years on most new projects. The advantages I find are that it is easy to setup and use and lends itself nicely to adapting product requirements that typically accompany a new project.
It's also nice that there is a large community and talent pool that supports and is familiar with MongoDB, so if you bring someone on to your project, you don't have to worry about someone getting up to speed on a less well-known document store.
In any case, I would consider it a viable option for any generic "new project" though the devil is in the details and there are certainly project requirements which could make it less viable.
But really, RethinkDB and Postgres are better in pretty much every way. If I was running my own stack, I wouldn't ever touch Mongo again.
My dream architecture is MongoDB+REST backend, pushing data changes as events over RabbitMQ, consumed by business logic C++Qt. Mongo would make this way easier if I could get triggers working.
You could use Meteor as your server, and talk to it over DDP from your frontend C++ app.
For example, my employer's production stack requires three Mongo servers. Stack Overflow, which has a much greater volume of data and gets far more traffic, uses MSSQL and consequently only needs one server.
That said, MongoDB is still plenty popular . It's just no longer the "hot new thing" that gets 5–10 posts a day on HN.
It may be that my projects are particularly well-suited to json docs and indexing, so perhaps I'm biased. Most of my APIs are consumed by single-page-applications like Angular, which already structure their data as json collections. So using a json-store (for me) makes things like 2-way binding a breeze.
Most healthcare apps are not "large" in nature and often have way more writes than reads, so many of Mongo's weaknesses don't show themselves in those applications.
I found the scaling not to be as easy as they led to believe. I also constantly bounced against the 10mb limit of the aggregation framework.
My biggest gripe, however, was data storage. It uses way more data then it should and it doesn't free up disk space if you delete data. For my use case (web analytics) it was a dud.
Supposedly TokuMX fixes many of the problems but I had already migrated to ES when I found out about it.
Managing replication and scaling can be time-consuming and expensive compared to other NoSQL stores like Redis and Couch.
So for production on serious projects, I would choose another DB before migration becomes expensive.