Does everyone hate MongoDB?

At our company we have a much bigger MongoDB dataset in production. I can relate well to your comments, since it is the same stuff that I hear from our developers as they defend Mongo after yet another horrific situation. They have a tough time admitting that Mongo is the problem, and instead always find ways to say that it was their fault.

This is such a strange thing for me to observe, but I think that it has to do with the fact that MongoDB works so smoothly initially with a default install that it hooks you in, and then later when you have a large dataset and it stops working well, it's hard to understand how what was such an amazing technology can now fail so badly.

It's also a huge problem that once you run MongoDB at scale, you desperately need experts to fix things, but it's so hard to find any so-called experts who can help. 10gen did a great job of marketing to developers, but unfortunately they seemed to spit in the face of DBAs and Ops people a long time ago by proclaiming them to be unnecessary and archaic. Running any significant MongoDB database in production requires as much expertise as someone running a big MySQL instance, but there isn't a community of database lovers around MongoDB who you can hire.

The DBAs and operations people I know dislike or even hate MongoDB, often for valid reasons that 10gen should address such as the as-yet-unfixed 'write lock' issue, code instability and inaccurate/misleading documentation. 10gen has done a great job at evangelizing to developers and making features that developers love. Now that 10gen has so much money, I hope that they can now afford to start making MongoDB a database that Ops people and DBAs can love.

As a final note, this ServerDensity guy is clearly looking at the world through mongo-colored glasses. It makes sense I suppose since he is all-in with MongoDB for his company. But we were using his service up until three months ago, and had a lot of problems with intermittent performance issues that seemed to be database-related since the site was still working and only certain pages would take 30 seconds or so to load. It's possible that the problems were temporary and no longer exist, but it brings home my point. If MongoDB experts can't make their own services 100% reliable, what hope does a regular startup have of getting MongoDB to work well at scale.

A developer may feel comfortable making the decision to go with MongoDB, but if they are wrong it won't cost them their job and they won't need to pull their hair out dealing with Ops issues all the time. If a DBA or Ops guy is being hired to manage a company's datastores, I don't see MongoDB (even 2.2) being a contender. At this point there are simply other DBs available that can perform the same or nearly the same without all the fussiness. Developers may be unhappy since nothing yet is as easy to develop on, but they'll be happier in the end when stuff 'just works'.

Agreed, lithium user here :-)

I haven't got a 32 bit version of Mongo, but people pointed out in the other thread that 32-bit version of mongod displays a little warning every time you start it saying it can handle only 2GB of data.

Can you confirm this (because I don't have the 32-bit version installed)? It still stinks, especially because it "silently failed after hitting the threshold", but I personally would feel better about 10gen if this little story is true (i.e. they warn you about it not only in downloads page, but every time you run mongod).

This article isn't exactly inspring me to give MongoDB a shot. I wasn't even aware Map-Reduce in MongoDB was single-threaded, doesn't that defeat the entire purpose? Isn't Map-Reduce an embarrassingly parallel algorithm?

If they're using a single-thread JS engine, can't they just multiprocess? No shared state, after all...

I am a huge fan of MongoDB and have been using it for years. That said, my default data store is PostgreSQL. I have to have a good reason for choosing to not use PostgreSQL.

I especially like MongoDB for data analytics: really handy for storing data and then doing experimental data mining. Putting a read replica on each server that does analytics/data mining works especially well (very good performance when MongoDB's indices fit in memory and the read mongo is on localhost to programs doing analytics).