Can I ask - were you actually affected by any of these issues you mentioned? Or was it just something you read on the internet? The reason I ask is because it fairly easy to have a productive discussion around the first - the latter is a bit harder.
However, I’ll give you the benefit of the doubt =), and assume this is from your firsthand experience.
Normally, when somebody claims " is too unreliable for that", they’re referring to actual cases where a database lost data - as in, you wrote data in, it was confirmed as persisted, and then when you went to retrieve that data, it either wasn’t there, or you got incorrect results.
Your first example - “fire and forget”, I assume you’re referring to the getLastError command. In older versions of MongoDB, write operations were usually done in two phases - one, to send the data to the server, and another separate call to retrieve the status code.
I may be able to shed some light here - MongoDB was actually originally part of a PaaS stack (hence the original company name 10gen). Eventually, they decided that the data persistence layer (i.e. what became MongoDB) was useful on its own, and spun it out into its own product.
For historic reasons, other parts of the stack were responsible for checking write concerns. Hence, when MongoDB was spun out as its own product, it was the responsibility of the developer to ensure they either made the appropriate calls themselves or set the write concern to an appropriate value, if their app couldn’t make the calls.
Of course, just because you didn’t follow the documentation doesn’t automatically meant you lost data - it would only happen if say, your network lost the packets in transit, or the box rebooted at the wrong moment. Then again, some of those events could be quite likely, in some environments.
This was documented from the beginning, and from memory, I think MongoDB had pretty clear warnings around it (although there’s arguments to be made on whether they were bold enough). Unfortunately, a lot of people glossed over it, or just deployed the product into Production without having time to read the documentation. So in version 2.4 the defaults were changed and if you wanted the old behaviour, you had to explicitly set that.
Your second example - you point to Kyle’s posts, where he dissects various database engines. I have a lot of respect for his work, and I’m not going to try to dissect it all - people far smarter than I have already discussed this openly - in fact, shortly after this post, Kyle filed a bug-report in the MongoDB bug tracker - you can see it right here:
https://jira.mongodb.org/browse/SERVER-17975
And there’s a fair amoutn of discussion between him and various developers on what the implications of his investigations are.
However, I think it’s quite disingenuous of you to mention Kyle’s post on MongoDB, then fail to mention that he’s made similar posts about most other database engines (RethinkDB, MySQL-derivatives, PostgreSQL, Riak, ElasticSearch, RabbitMQ, Redis etc.) and all of them have various issues, to varying degrees.
As I said in my first post:
There are certainly issues with MongoDB, as there are with any database system. But I don’t think throwing around blanket statements like this helps progress the discussion.
You came out swinging, and said “MongodB is too unreliable”, with no data or evidence to back your claim. I think you did the community a disservice, by not either providing at least some evidence for your claims, or some explanation for why you felt that way, and/or what you thought was a better choice. It’s very easy to just say “X sucks”, but harder to actually say “X sucks because of ABC”, or “X sucks, and I think we should do Y instead because of ABC”.
I don’t know if anybody can categorically say whether MongoDB was the “right” choice for Meteor - although I suspect in many ways it played well into the whole “easy to get started” vibe of Meteor. However, if you’d like to progress the discussion, you really need to step up.