Fist of, this looks like a fun project. I haven't seen the implementation but it looks they built the new database using the current state of the art from db / data structure literature (distributed b+ trees).
On a semi-unrelated rant... I do have to say that Sql/NoSql/MoarSql nomenclature is getting old. The databases we're talking about are relational databases. The fundamental properties of these databases (selection, projection, aggregation, joins, et al) are properties of relational model (databases) and stem from relation algebra and calculus.
It just happens that the most common way of interfacing with these relational databases is the SQL language.
And, as far as languages SQL is kind of meh. It's really not that easy to work with / write (non-trivial queries). And, more importantly it's kind of a pain to generate via code.
As I understand it (I might be wrong) this engine basically automates DB partitioning by creating distributed nodes. By donig this it scales without having to deal with replication, but at the same time it is still fully relational. I'm not sure whether it allows ACID transactions. I'm also curious about how it could be evaluated against the CAP theorem. Interesting.
Pretty much all these distributed databases at their core somehow handle the partitioning of data. Even if sometimes it's just throwing up your hands and saying there's a user has to provide us a partitioning function. That's true in non-relational databases (Hbase, Casandra, Mongo) and in relational ones (Volt, Vetica, this db).
It looks like here the data structure enabling partitioning is based on prior art distributed B+ Tree.
From the paper it looks like it allows for full ACID transactions. At least to the physical extents that ACID is possible.
On a semi-unrelated rant... I do have to say that Sql/NoSql/MoarSql nomenclature is getting old. The databases we're talking about are relational databases. The fundamental properties of these databases (selection, projection, aggregation, joins, et al) are properties of relational model (databases) and stem from relation algebra and calculus.
It just happens that the most common way of interfacing with these relational databases is the SQL language.
And, as far as languages SQL is kind of meh. It's really not that easy to work with / write (non-trivial queries). And, more importantly it's kind of a pain to generate via code.
END RANT