The most counterintuitive part of this is probably that one instance of a storage manager can talk to a whole key-value cluster (e.g. one managed by HDFS); thus, this is not a classic shared-nothing nor sharded (transparently or otherwise) approach. Rather, each NuoDB storage manager sees the whole database.

NuoDB transaction engines and storage managers run on different machines.

Each database has its own transaction engines and storage managers; transaction engines for different databases can run on the same machine.

Replication factors can be different for different databases.

Local replication gives high availability and elastic scale-out.

Remote replication gives disaster recovery.

Wrinkles include:

Transaction engines and storage managers have very similar code.

You could run everything on one machine if you really insisted.

Conversely, NuoDB fondly thinks that it makes sense to run transaction engines on the same machines as your application servers. (I’m more skeptical, since app servers and DBMS are both heavily consumptive of RAM.)

[…] who has NuoDB as a client, has been given a look under the hood, and has analyzed NuoDB's architecture and claims, concludes that "no new DBMS could possibly justify NuoDB's hype. But NuoDB is an […]