The result is that many developers who bought into the hype train are now salty because they encountered the limitations at unexpected and unfortunate moments that might have cost them uptime or data.
For most applications I usually use Postgres.
Then they chucked it over the fence to Ops who were expected to make it work in Production, and everything about it was found to be woefully inadequate, and the Ops guys were forced to carry the can. Those guys feel - quite rightly - that they were shafted by MongoDB, both the company and its fans.
Other things like continually pointing to each other, not figuring out a master for hours has made some people tear their hair out, despite the documentation saying it should behave in a sane way.
- had a global write lock.
- mmap was the extent of their io and memory management
- called rand() in in client to decide if it should report errors
- said a write was committed before even sending it out
- released benchmarks that measured how fast they could put data into local RAM, but compared it to real dB's
- lost data/corrupted on 32 bit builds and dismissed that as being by design
- is generally better off replaced by postgres but hyped by people that don't know any better
That's off the top of my head. I'm sure there are competent users and it makes sense in some cases but the general feeling is that it's over hyped for the little it is. Their early mistakes make people very cautious about trusting them with important data.
And by over hyped, I'm also taking about people that go on about how amazing it is to have a document store, but ignore the obvious idea of using pg and making a table consisting of (key, document) and using XML or JSON operators on top.
I might be totally wrong.
Without telling you.
There's "one lonely dude complaining on the internet", which you can safely ignore. And there's "half the audience has horror stories to tell", which should probably be a red flag.