That's interesting, thank you. In practical terms, what does ACID provide that compare and set does not?

The page linked goes into more detail, but among other things, Compare and Set operations are only concerning one data element at a time - meaning you cannot do Atomic updates to multiple keys. The ability to do multiple key updates atomically makes it possible to build higher level abstractions by reliably combining data from multiple keys under concurrent workloads.

Basically, transactions that can span an arbitrary number and set of keys are what makes it possible to build rich data models from simple ones. SQL databases are a perfect example of this - most use a simple transactional data store on the bottom to store complex relational data structures. A single SQL operation may require many key-level updates - but this is OK if you can wrap them all in ACID transactions.Without ACID transactions you can't guarantee data consistency because keys will be getting updated at different times, allowing for a mix of old and new values.

It's a shame to see vendors trying to change the meaning of ACID to fit the limitations of their databases. It means more confusion and bad decisions in a market that needs clarity and honesty for people to make the right decisions for their applications.

Yes, I really hate this. When I first saw that Aerospike support ACID transaction, I thought, Wow, it is really amazing. After I read the paper, That "ACID" means one key transaction, it make me dispoint, I don't even want to see there code again..

Well while claiming ACID specifying that it is only for single record transaction seems to stated clearly.

As you were describing, there could be many changes performed when doing single record operations as well e.g multiple column updates / secondary index updates.

Does it really need to be multi record transaction to claim ACID ??

I'm not going to comment on whether or not Aerospike is ACID, I have no idea, but I can give a bit of info on CAS vs ACID.

CaS (Compare and Swap, or Compare and Set; they're almost identical, and don't really have a clear distinction) is the process of validating a record's value before performing an update. This helps a lot with Consistency (the C in ACID), but doesn't guarantee the other three (Atomicity, Isolation, and Durability).

Aerospike might have systems in place to address all of ACID, but if they're claiming CaS is ACID then they're just lying.

Look at the Wiki page on ACID ( http://en.wikipedia.org/wiki/ACID ), it's actually pretty good.

A straightforward usage of CAS doesn't provide transactions. In other words, there is no way to update multiple records atomically.* For instance, perhaps you wish to update two balances to reflect the result of the transaction. Using CAS, a reader may observe that only one balance has been updated -- the reader sees inconsistent data.

* no sane (or performant) way.

It's called marketing and as evidenced by MongoDB, people will believe anything you tell them. Web scale my ass Mongo.