The core code is written in C, but they're definitely using Lua in places, I believe they've incorporated some code from AlchemyDB... https://code.google.com/p/alchemydatabase/

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

They don't have ACID transactions. We had to put up a page to dispel some of the misuse of the term ACID. Aerospike's excerpt:

"Aerospike does not provide true ACID transactions. Just like Cassandra 2.0, Aerospike only provides compare and set, and misleadingly labels it as ACID."

https://foundationdb.com/acid-claims

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.

"just look at the cost savings"

Purported cost savings.

There's an article from an AppLovin (RTB ad-network) engineer (http://liviutudor.com/2014/07/24/of-advertising-and-scaling-...) talking about how Aerospike DB is essential to their serving up 15B (as in billion) ad impressions per-day.

Again, an alternative example from the database vendors. Please, display some critical thinking.

Critical thinking includes not suggesting that someone should prove a negative. Those are independent benchmarks with the sole 'violation' of being re-posted on the vendor's site. Unless you can provide metrics that disprove them, they stand.

It's an example case from a customer of the database vendor. I'm unlikely to find anything better until after people start playing around with the open source version.