"MongoDB is designed to be run on a machine with sufficient primary memory to hold the working set. In this case, writes finish extremely quickly and therefore lock contention is quite low. Optimizing for this data pattern is a fundamental design decision."
Yeah, well, that's a problem. MySQL and Postgres perform dramatically better if you keep everything in memory, too -- but they don't fall over if they have to hit the disk. (And yes, they can handle lots of concurrent writes, even when the working set is larger than RAM.)
I have no particular bias for or against MongoDB, but arguing that it's peachy because its biggest limitations were designed-in from the start isn't a winner. Some of us want tools that aren't going to fail under reasonably expected application loads. Also, arguing that Enthusiastic Developers are Working Really Hard on fixing those limitations isn't especially compelling (I'm still waiting for Enlightenment 17...)
Sometime the best marketing for your product is stupid marketing of competitor's product. Those that worry about their data when they read what supporters are saying and they hear "writes finish extremely quickly and therefore lock contention is quite low" because "it is all in memory" will turn around and walk away.
Some who are nice will take the time to explain and criticize that is such a bad design (and those will be deemed as haters), most will just turn around and find something else.
> but arguing that it's peachy because its biggest limitations were designed-in from the start
My beef with them is with the perceived dishonesty in their marketing (and it must be the 4th time I've said, sorry if you have to read this phrase again). They basically never made the trade-off obvious on their front page. So at worst it was dishonesty, at best it was just a bad thought-out design that wasn't fixed until a couple of months ago. Sorry, I cannot accept their product, because I have doubts in their competence.
Very simple, because the product appears to be severely overhyped and underdelivered.
Your primary datastore is not something you want to be taking risks with. If you are looking for a toy you can use any DB you like, including Mongo. If reliability is important to you why would you want to serve as a guinea pig for some seriously buggy product?
NoSQL has its place where you have a very specific use case to be solved, but your primary datastore of record is rarely one of those. Mongo specifically is being positioned as a general-purpose datastore and because of that (for me at least) it fails to demonstrate any value whatsoever. Every time I ask any Mongo advocate for why it is a good choice the most compelling thing I hear is "schema-less DB" and "speed of development". Guess what, maybe if your database forces you to think about your schema, data layout and the query load you are going to have to develop a more reliable application. Having to think through your schemas in advance actually forces you to be disciplined and prevents you from making errors.
Once you are ready to confront the reliability issues SQL databases that had years of hardening against all sorts of risks look like a safe harbor. MySQL is not too bad for Facebook and Quora, what prevents you from properly tuning it to work for you?
Probably because there is absolutely no mention of the limitations - especially the durability issues on the website.
People who want to store schemaless documents are going to approach MongoDB as a safe data store and get some very nasty surprises if don't have the proper configuration. You would expect a database to run slowly if misconfigured, but never to lose data.
I think it's kind of missing the gist of the criticism that mongodb advertised itself as so much faster than traditional DBs and yet it turns out its not reliable.
And for all the painful stories of foursquare and others having meltdowns, it seems to be really unreliable.
Yeah, well, that's a problem. MySQL and Postgres perform dramatically better if you keep everything in memory, too -- but they don't fall over if they have to hit the disk. (And yes, they can handle lots of concurrent writes, even when the working set is larger than RAM.)
I have no particular bias for or against MongoDB, but arguing that it's peachy because its biggest limitations were designed-in from the start isn't a winner. Some of us want tools that aren't going to fail under reasonably expected application loads. Also, arguing that Enthusiastic Developers are Working Really Hard on fixing those limitations isn't especially compelling (I'm still waiting for Enlightenment 17...)