I've just entered Project Voldemort (a NoSQL key-value datastore) site, and saw something interesting:
"Unlike MySQL replication, both reads and writes scale horizontally"
Well, seems like this statement tries to compare Valdemort with a MySQL traditional RDBMS. Yet, MySQL Cluster is also part of the MySQL solution family. It can scale writes and reads horizontally.
AFAIK MySQL Cluster has the ability to scale, but it is really a manual process to do so. In fact, it takes more planning and more hardware to do such scaling. Here is why:
According to "Guide to Scaling Web Databases with MySQL Cluster" (October 2011 Whitepaper), page 5 paragraphs 4,5 under the subheading 'Auto-Sharding':
MySQL Cluster is implemented as an active/active, multi-master database ensuring updates made by any application or SQL node are instantly available to all of the other nodes accessing the cluster.
Tables are automatically sharded across a pool of low cost commodity data nodes, enabling the database to scale horizontally to serve read and write-intensive workloads, accessed both from SQL and directly via NoSQL APIs. Up to 255 nodes are supported, of which 48 can be data nodes ... MySQL Cluster excels at both aggregate and per-node performance, eliminating the requirement to provision and manage racks of poorly utilized hardware.
Scaling can be automatic, but within the confines of the MySQL Cluster architecture.
MongoDB can autoshard by means of running a routing program called mongos in front of shards. The router knows where data is located, so applications can connect to it and issue requests normally. There is no apparent limitations on the amount of servers to store data and communicate requests.
Just comparing MySQL Cluster to MongoDB, you find auto-sharding available in both. The major difference is that you are limited to 48 data nodes, even though a maximum of 255 servers can be configured for MySQL Cluster infrastructure (The remaining 207 maximum nodes make up SQL nodes [providing mysqld process and other APIs] and management nodes [providing ndb_mgmd process]). MongoDB does not have such an architectural limitation. MySQL Cluster can, by design, run out of elbow room.
Saying that" read and writes scale horizontally" would quickly apply to products that internally perform this. Using MySQL Replication, this statement holds true. Why? MySQL Replication is asynchronous (even MySQL 5.5 is Semisynchronous, at best), whereas MySQL Cluster and MongoDB (as well as other NoSQL Databases) are synchronous with the backing of ACID-compliance.
Disclosure: I'm part of the MySQL Cluster product team
The 255 node limit is for a single cluster. You could have multiples of these supporting your application, with replication between them.
It is also important to consider per-node performance - in recent tests, MySQL Cluster achieved 6.8m QPS across 8 x physical Intel servers, configured with 2 sockets and 24GB of RAM (ie low cost, commodity): http://mysql.com/why-mysql/benchmarks/mysql-cluster/
Sharding in MySQL Cluster is automatic - it happens at the database layer and is based on hashing the primary key by default. This tends to give better shard distribution than alternative auto-sharding mechanisms using range-based partitioning
There is a decent answer here that compared application to database level sharding, and the benefits of the latter: MySQL Sharding vs MySQL Cluster
