We use MongoDB for storing tons and tons of analytics data for which we don't care if some stuff occasionally gets lost in a server crash. The data really fits MongoDB well and it would have been a nightmare if we were to use an SQL database for this. But for bank transactions we wouldn't even consider MongoDB.
The write lock might be a problem for some people. On the other hand MongoDB supports easy sharding, much easier than with SQL. Sharding allows us to scale horizontally which is a huge plus for our data.
And, yes, the speed improvements to the ruby driver are very much appreciated :)
It is absolutely OK to lose analytics data occasionally, and indeed with the variety of ways to bork that (js is off, user agent prefetches undisplayed page, bot action, etc) if your stats aren't robust against it you are screwed anyhow.
For instance, I routinely delete web server logs older than 30 days, on the assumption that if I didn't need it in the last 30 days I'll probably never need it. Every now and then this bites me and I need more than 30 days data to test some assumption, then I will just have to wait for a bit. (for events that occur infrequently enough).
Website visit counters are a great example. I don't think many people care if a few visits get lost once in a while.
Again this debate comes down to how you structure your data and picking the best model for that and then figuring out how/if you can deal with its idiosyncracies. The single server redundancy issue has been beaten to death and for any production application should be planned in from the beginning regardless of the database.
As for server durability, yes, it has been beaten to death. Yet, I still talk to developers that either have no idea that's how Mongo operates, or don't know what save mode has to offer.
If you're really worried about durability, you should be replicating anyway--and, ideally, over 3+ nodes at least two datacenters. I've always just assumed MongoDB was designed around that idea.
If your disk is saturated during a sync due to a lot of writes, you might see the write lock at 100% for several seconds and everything will momentarily grind to a hault. If you set sync delay to zero and just rely on the OS to sync, you'll never see this happen.
We're using MongoDB in production and have a few boxes setup. One runs without sync delay and is used to process feed data. If Mongo crashed, and the data was irrevocably lost, it wouldn't really be the end of the world as the data only hangs around for about ten days anyway.
The second box runs with a sync delay and is used to store session data. In either scenario, Mongo is designed to be run with a slave at all times since it's not single server durable.
Regarding performance, the feeds box without sync delay can consistently write 25,000 records per second without ever going above 75% write lock. I find that pretty amazing. Doing preliminary benchmarks and performing batch writes that completely lock the server, I was getting about 250,000 writes / second.
