1. evaluate the default settings with which MongoDB ships and
2. evaluate MongoDB performance with more strict,
consistent options and learn that it's quite slow and
3. look at my comment above
... then you will quickly see that MongoDB is not RDBMS like at all in terms of data safety and consistency goals.
Currently 10gen is shooting for light-weight web workloads to spread the product, and they're very successful.
Well, yes, it would be fair to say that when you need to use MongoDB instead RDBMS you have to make safe=True commits all the time (otherwise you can really lost piece of them). I didn't do any benchmarks, because for usage like this I am completely ok with RDBMS, and use MongoDB in more "warehouse"-like use-cases (statistics, caching, long-running m/r on data etc.)
So MongoDB gets it's own niche: use it for "not 100% important data", but instead you get really high availibility of MongoDB cluster, really high speed and document-storage.
What you said about speed on safe commits is really interesting for me. I mean, of course they're slow consequentially, but in parallel they should be just as fast. Or am I wrong here?
MongoDB has very nice tunability. The new version ships with journaling turned on by default.
You can specify `safe`, which means the data will be written to the journal. You can also specify `fsync`, which means additionally the system will issue an fsync on the journal. Additionally, there's the question of the replication protocol, `W` in MongoDB. What I said is that if you turn on `W=2` it will be slow. You should also know that even with `safe` and `fsync` you may lose data if running in `W=1` mode if the master goes down in your replicata set. See my comment above and the reply from a MongoDB guy.
Currently 10gen is shooting for light-weight web workloads to spread the product, and they're very successful.