memSQL, AFAIK, was built for highly concurrent reads and writes. It uses lock-free in-memory data structures, couple that with an eventually-durable mode, in addition to optimizing queries by the way of re-compiling SQL to CPP (something similar to what HHVM does for PHP), I think it would result in performance gains in certain (and not all) use-cases.
memSQL, if we dare simplify, is really a high-throughput cache front-ending an eventually-durable datastore.
I wonder how would RocksDB + a disk-backed DB measure upto memSQL.
To put in another way - does any bank would accept eventually-durable as its financial transaction storage?
More seriously, without error propagation to the client, such that it could "know immediately" which one of his transactions failed, there is no durability at all.
Ask all these telecom guys - without immediately returned ASK packets and timeouts a protocol cannot be called "reliable".
MemSQL has two modes (if I am right): synchronous and asynchronous. I believe, if you're a bank, you'd want the first one. But if high throughput is your priority, you can afford to sacrifice durability for that, I think MemSQL would be an extremely fast solution compared with other disk-first datastores.
One thing that memory-first datastores (MemSQL, VoltDB) would be really good at is lots of reads.
If the data is replicated across a number of machines, then determining the durably is a more complex task. If sending data to the cluster blocks the user's write on a response from the quorum of the cluster, then I think the cluster can be considered reliable data store, even if the cluster nodes don't necessarily write to disk immediately or at all. Perhaps they keep the data in memory forever, and there are enough replicas that the chance of data loss (through all replicas being down at once) is low enough to accept. (It's conceptually similar to replicating across many disks and losing all the disks at once, although I agree, it seems intuitively a lot more fragile than disk based replication)
A more realistic model might be in-memory replication by quorum followed by buffered writes to disk on all replicas too. Since there are many replicas, it's not unreasonable to "persist" data in RAM on the many repliacs, but we also get the full benefits of disk persistence after a short time.
Just thinking out loud here.