[jlaustill]

This is great news. Historically I've accepted the risk of data loss and coded checks when needed. I will never rely on my database, regardless of which one I am using for complete data consistency. It is, however, nice to see strides being made towards even better robustness. Go MongoDB!

[koolba]

> I will never rely on my database, regardless of which one I am using for complete data consistency.

I can't imagine developing any software that involves relationships between entities that does not have data consistency. Check constraints, foreign keys, and data type validation all provide a minimum sanity level of the underlying data that allows your mind to focus on more important things. Otherwise you're entire application is going to be littered with those same sanity checks.

I'm not saying that all apps need that type of data store or that there isn't room in this world for NoSQL stores, I mean specifically that complicated interdependencies and validation checks lend themselves well to the relational model.

[mushi]

I think maybe the doubt is based on case like https://aphyr.com/posts/282-jepsen-postgres which all systems are subject to.

[continuational]

That's not a case of inconsistency. There are just three outcomes for a transaction: Committed, Aborted and Unknown.

The client will never experience Committed unless it really is committed, and thus never report that it was successful to the user.

[throwawayish]

Uh, no. That article is a bit of a long winded way to say that 2PC with timeouts is 2PC with timeouts.

[aphyr]

It might be better to think of it as a limitation of two-generals, rather than 2PC in particular.

[beachy]

I'm sure they exist but I can't imagine any project where I would want to factor in data loss from my database.

At the very least I'd want to know exactly how much data loss we are talking about, which is probably harder to answer than just using a platform that doesn't suffer data loss in the first place.