> The fact that [Cassandra], riak, etc aren't ACID isn't a point against them; it's a calculated tradeoff.
Actually, not being ACID is absolutely a point against them.
Riak at least has an good reason: it's eventually consistent. They are getting the advantages of better latency and disconneced-operation.
But, if you look at MongoDB, Cassandra (as it is usually config'ed), and HBase they are actually all strongly consistent. They've already accepted the strong-consistency side of the CAP theorem tradeoff. There is no remaining reason not to have transactions at that point, but they don't. This isn't because of some fundamental tradeoff, it's because making transactions run correctly and fast is really hard and they haven't yet cracked that problem. I bet it's on all of their roadmaps. If and when they add multi-key serializable ACID transactions their products will be purely better for it.
We're talking about a few DBs here, but I'm just going to focus on Cassandra, as Mongo is a lost cause, and I don't know much about HBase. However, my arguments apply to all AP systems with tuneable consistency.
I think you're saying that people use Cassandra with consistency=ALL everywhere to get strong consistency? In that case, sure, then they should look at something else. Potentially even the database your company produces. However, that is a strawman; Cassandra was designed to be an AP system. Later additions like tuneable consistency and lightweight transactions are a compromise, and implementing something as crazy as ACID transactions on C* would be insane. Like, totally stupid. It is so far from the core goal of an AP system, that I would be very worried about the leadership of the project.
I like my databases to do one thing, and do it well. That's why I like basic C*: it's an awesome AP KV database. Features that have been added later have generally been syntactic sugar (CQL, indexes, multi column indexes, user types), or compromises (tuneable consistency, lightweight transactions). But it still remains an AP system at heart. And because of that, ACID transactions would _not_ improve the product. It would all but destroy it.
You should probably mention that you were a founder of FoundationDB if you're going to comment on articles about it.
Actually, not being ACID is absolutely a point against them.
Riak at least has an good reason: it's eventually consistent. They are getting the advantages of better latency and disconneced-operation.
But, if you look at MongoDB, Cassandra (as it is usually config'ed), and HBase they are actually all strongly consistent. They've already accepted the strong-consistency side of the CAP theorem tradeoff. There is no remaining reason not to have transactions at that point, but they don't. This isn't because of some fundamental tradeoff, it's because making transactions run correctly and fast is really hard and they haven't yet cracked that problem. I bet it's on all of their roadmaps. If and when they add multi-key serializable ACID transactions their products will be purely better for it.