Riak is interesting, but its performance characteristics are unfortunately interesting in a negative sense.<p>First, single-node performance is awful. You would think that even on a single node, simple key/value lookup would be able to compete against something like Postgres; after all, the read pipeline should be much simpler. But it doesn't come close, in my testing. Not just key/value lookups; it's also dog slow at chasing links, and scales very badly with the number of links.<p>Now, Riak is intended to be deployed on many nodes, but in my testing with three nodes I did not see a significant increase in performance. The overhead seemed to be constant. In a master-less, distributed database, some compromise on performance is acceptable, but Riak looks much worse than would be acceptable.<p>Riak is focused on random access. Sequential access similar to that offered by Cassandra and HBase just won't scale beyond a few hundred objects. This problem is made worse by the fact that a Riak "bucket" isn't really a bucket, but a namespace; all data in a Riak database resides in the same storage, and bucket operations simply filter that data based on the bucket name. This means that any sequential access is off the table.<p>The Riak people suggest using links in order to emulate sequential access patterns and entity relationships. For example, if you want to blog post with bunch of comments, you would store the post in one key, and then comments in other keys, and then use child/parent links to glue them together. Unfortunately, this seems to scale very badly with the number of objects linked.<p>Not just read performance, either; it seems links are stored in a single chunk whenever an object stored, so when adding a single child, you have to write all children back to the object! Obviously that does not scale to thousands or even millions of objects. For a database that has no other means to deal with relationships, the weakness of the link feature is serious.<p>After all, you would face the same problem if you stored the list of objects as a key value (you have to rewrite the entire object every time, since Riak does not have partial updates), and since it's not feasible to scan keys based on prefix, for example, you end up with no alternative. I suppose you can use Riak Search, but last I checked it was built on top of Solr, which is not fast.<p>There are various minor annoyances, too. For example, unlike Cassandra, there is no operation to delete the entire contents of a bucket -- something which you want to do before/after unit tests --, so you have to sequentially enumerate the bucket's keys and delete each one, something which is just excruciatingly slow.<p>Here is a test case I wrote in Ruby to test performance: <a href="http://dl.dropbox.com/u/12091499/Share/riaktest.tar.gz" rel="nofollow">http://dl.dropbox.com/u/12091499/Share/riaktest.tar.gz</a>. It contains a script to test similar operations/queries against Postgres. The included Riak test results are for a three-node dedicated test cluster (plenty of CPU, RAM, I/O). I am open to the possibility that the config needs tuning, of course.