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:

#MySQL Cluster

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

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.

#Conclusion

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.

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:

MySQL Cluster

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

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.

Conclusion

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.

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:

#MySQL Cluster

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

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.

#Conclusion

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.

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:

#MySQL Cluster

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

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.

#Conclusion

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.

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:

#MySQL Cluster

According to "Guide to Scaling Web Databases with MySQL Cluster" (October 2011 Whitepaper), pages 5,6 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

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.

#Conclusion

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.

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:

#MySQL Cluster

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

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.

#Conclusion

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.