Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

MySQL Cluster

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.

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