From what I've read it could easily surpass Mongo, just look at the cost savings... http://www.datanami.com/2013/09/06/aerospike_says_secret_to_... "The second comparison (a video ad serving platform) had much bigger requirements, including a 5TB database processing 500,000 TPS. The hybrid SSD-DRAM setup running the AeroSpike database was able to handle the load with just 14 servers, at a total cost of $322,000, compared to 186 servers using NoSQL running on clusters of servers that use a lot of DRAM and cost $5.6 million."
They´re ACID compliant as well, which Mongo is not (AFAIK)... https://www.youtube.com/watch?v=nnxj77NNEeg
Purported cost savings.
"Aerospike does not provide true ACID transactions. Just like Cassandra 2.0, Aerospike only provides compare and set, and misleadingly labels it as 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.
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.
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 ??
* no sane (or performant) way.