[dm_mongodb]

Single server durability is coming, v1.8 in the fall. We chose to prioritize some other things before that. http://jira.mongodb.org/browse/SERVER-980

We've always clearly said don't build a bond trading system with it. Our philosophy is one-size-fits-all is over; use the right tool for the right problem.

Based on how I like to define the term, there is nothing in the NoSQL space that does full "ACID", including complex transactional semantics involving many objects, on many server clusters. That is ok : the perf + scale problem isn't really solvable if you don't give on something.

[ericflo]

If MongoDB doesn't have single server durability, what kind of durability does it have?

[angelbob]

Clustered durability. You can request, per-write, "don't return until this data has been persisted to N other servers," with N chosen per-write.

So if you're running master/slave and choose N to be 1, you're durable (at the two server level). Run 5-replica sets and choose N to be 3 or 4, and you're basically guaranteed durability. One of your nodes goes down hard and bad things happen? You have four additional clones of it sitting and waiting to be copied.

This is actually more durable in cases of extreme hardware failure like, say, your RAID controller going out. However, it requires that you spend more on hardware. So do several other things Mongo does, like using a lot of RAM and disk to get faster writes, so that's in keeping with a lot of their other design decisions.

It's not perfect for every project, but it's a great choice for most of the same projects where you'd use Mongo in the first place.