These "NoSQL" comparisons are a tricky thing, inasmuch as this is a very volatile space with a lot of really interesting development happening. Furthermore, benchmarking a handful of storage options that are really only alike in that they share the same thing which they are not (relational, SQL) is a lot like running road tests on a handful of cars that are not Honda Civics.<p>I made the foolish decision a while back to choose a data storage option based on benchmarks and hype, and I'm currently paying for it by having achieved spectacular launch failure and now completely rearchitecting my backend.<p>NoSQL emerged only after a decade or so of webscale challenges helped us finally realize that everything only <i>looked</i> like relational nails because the only tool we had was SQL hammer, and that tackling every data warehousing problem with SQL was coming at the cost of money, engineering hours, and headaches. Now that viable, production-ready alternatives have become available it's important that design decisions to go beyond seeing problems as not-nails and seeing them instead for what they are.<p>Are you looking for reliable, versioned master-master replication for embedded devices? Might want to consider Couch. An obscenely fast caching tier that need not persist to disk? Sure, check out Scalaris. A fully distributed and pluggable map-reduce architecture capable of storing a metric fucktonne of data? Hbase might be for you. And, it should go without saying, there are still and there will always be problems for which SQL is the best solution.<p>In any event, an invaluable starting point is Richard Jones' post at Metabrew discussing research on a number of options for Lastfm: <a href="http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/" rel="nofollow">http://www.metabrew.com/article/anti-rdbms-a-list-of-distrib...</a>