Mongo is fine until it's not. It's been fine for us for many months, but once you hit its limitations, it's pretty horrible. We're in this situation right now and we're seriously considering moving back to MySQL or Postgres.
Basically, "it doesn't scale" unless you throw tons of machines/shards at it.
Once they fix a few of their main issues such as the global write lock and fix many of the bugs, it could become an outstanding piece of software. Until then, I consider it as not ready for production use in a write-intensive application. Knowing what I know now, I certainly would not have switched our data to MongoDB.
Have you considered Riak? (I ask mostly because I've been looking at both, having a little MongoDB experience but having heard great things about Riak.)
Riak is definitely an option I'll consider, but experience has taught me one thing: most of the time it's better to stay with the most mainstream tools, such as MySQL, even if that means not using the absolute best tool. As long as it gets the job done and is "good enough".
There are better options than MySQL out there (such as Postgres and Riak probably), but when shit hits the fan in production and you need to quickly bring your servers back up, you'll be happy you chose a tool that has a lot of outstanding consultants and immense amounts of documentation. Finding help for MySQL is very easy. Help for Riak or even Postgres is much more scarse. Also, MySQL is very likely to still be around in a few years. We can't say the same for most of the new NoSQL stuff.
I tried to stay true to this as much as possible in the past and it served me well. I made this mistake with MongoDB, however.
That's fair. Riak seems interesting to me more from an almost academic perspective; as I said, I haven't used it. My go-to are MySQL and Postgres, too (though I use Redis a decent bit as a communication pipeline).
My experience is that this is true of every database system (relational or non-). The thing is that they all break in different ways at different points, and so the smart thing to do is make choices based on that information.
The stupid thing to do is write blog posts about how Software Package X sucks and nobody should use it for anything.
I work with databases in extremely high OLTP workload environments since 20 or so years.
We're talking enterprise products, mostly Sybase, some Postgresql and very little Oracle.
Have I encountered bugs?
Sure, tons of them. Some of them grave enough to render the specific version of the database software unusable in the context of the project I worked on.
However, in all this time I probably dealt with no more then 3 - 5 corrupt databases, none of them went corrupt due to a database bug. Usually it was related to hardware failure,
Arguing that database corruption is inherent in the design of the product is, from a database perspective, beyond the pale.
A database "breaking" is absolutely not the same as a database blasting your data into corrupt confetti.
If you actually go through the various stuff posted, you find a recurring theme: people who lose data fall into a pattern of "well, they told me not to do this, but I did it anyway, so now it must be their fault".
Which, I think you'll find, is a far cry from "database corruption is inherent in the design".
But hey, learning that sort of thing would require reading; much easier to jump on a bandwagon, badmouth a product and downvote anyone who disagrees, amirite?
And everything is wonderful! Complains and criticism should be removed from the world.
Nice job putting words in my mouth.
Look, I know it's fashionable right now to hate on Mongo for whatever reason, but the simple fact is that everything has a breaking point. Saying "I ran into this product's breaking point, therefore nobody should ever use it" (the gist of many of the recent posts) is frankly stupid; instead, we should be asking when and how and why something breaks when evaluating it, since that'll give us an idea of what fits specific use cases.
Basically, "it doesn't scale" unless you throw tons of machines/shards at it.
Once they fix a few of their main issues such as the global write lock and fix many of the bugs, it could become an outstanding piece of software. Until then, I consider it as not ready for production use in a write-intensive application. Knowing what I know now, I certainly would not have switched our data to MongoDB.