Five signs you have outgrown MongoDB

Sign 1: You’re concerned about the business impact of database reconfiguration

Once you have been working with a cluster of either Aerospike or MongoDB for a while, there will come a time when you will need to expand or shrink the cluster.

With Aerospike:

• To scale out, simply add one or more nodes to the cluster, and the system will auto-rebalance.\

• Data migrations are automatic without existing nodes needing to be taken offline.

• Node removal works the same way – automatically and without service interruptions.

With MongoDB:

• You can upgrade from one tier to another, increase storage size, and expand the size of a replica set.

• You can scale down a replica set to a smaller replica set.

• You can upgrade a replica set to a sharded configuration, but you cannot go back to a replica set.

• You get service interruptions while you scale up or down or adjust tiers.

Note that with MongoDB, resharding based on a new shard key is a painful process involving downtime.

Sign 2: You’re looking for higher performance, and not just relative to an RDBMS, but for real-time applications

Aerospike conducted a 10TB benchmark test versus MongoDB on a document dataset where Aerospike had nine (9) times the throughput with 12 times better latency on less than one-third the VMs:

Table 1 (From benchmark white paper): Aerospike vs. MongoDB results summary from 0-10TB as data is generated.

Sign 3: As you scale your applications, you’re concerned with runaway costs

Per the aforementioned 10TB benchmark comparison of Aerospike versus MongoDB, the cost advantage of Aerospike can be up to 5.4 times better, depending on Aerospike software licensing costs (contact us for details).

Table 4 (From benchmark white paper): Total cost of ownership (TCO) for Aerospike vs. MongoDB for 10TB document workload.

Sign 4: You want your application to be highly available

If your application needs to be online with four or five nines uptime, this can be a problem in MongoDB. MongoDB’s default configuration prioritizes consistency over availability. In the event of a primary node failure, a shard can become temporarily unresponsive for several seconds to a few minutes during the process of electing a new primary.

Aerospike, by contrast, can prioritize either high availability or strong consistency - the choice is yours. Aerospike does not have a single point of failure with all the nodes being equally balanced. With MongoDB, the primary of every shard is the only one accepting writes for that partition. When this node goes down, the entire partition is down until a new primary is elected.

As evidence, the below graphs from the aforementioned benchmark white paper show how resilient Aerospike is and how problematic MongoDB is when a node goes down:

Figure 15.2 (From benchmark white paper) - “Zoom in” of Aerospike during a node failure @2:26: no loss of service with service only dipping from 149k to 126k TPS.

Figure 16 (From benchmark white paper): Zoom-in of MongoDB showing failure when issuing a node restart to test reliance; a large performance drop is seen from ~36k to 7.2k TPS over a 40-second period.

Sign 5: You’re concerned that scaling will affect your performance

In MongoDB, data distribution across the cluster is indeed tied to how data is modeled and sharded. Properly dividing the data space into evenly sized shards is crucial to avoid imbalances in the cluster. If the sharding is not done correctly, some nodes can end up with much more data than others, leading to an imbalanced cluster and potential performance issues due to this (often) manual sharding process.

When scaling MongoDB, adding more shards is required. While this is primarily an operational task, the effectiveness of the scaling depends on the initial data modeling and sharding key. If these were not optimally designed, application changes might be required. So scaling is not only an operational task, but can require reprogramming your application.

Aerospike, by contrast, has predictable performance, from gigabytes to petabytes. Aerospike achieves high performance without relying on data caching. Every request to Aerospike delivers consistent performance, comparable to MongoDB operating with enough RAM to store the entire dataset in memory.

This was tested, for example, in the 10TB benchmark of Aerospike versus MongoDB, whereby MongoDB’s performance degraded by over a third:

Table 1 Excerpt (from benchmark white paper): Aerospike vs. MongoDB Atlas results from 0-10TB as data is generated.

Many customers have already made the switch

Many customers get started with MongoDB until their needs change - or they realize that there are better options, like Aerospike.

• Top 3 Global Brokerage: Considered MongoDB, but it couldn’t provide low read latency at high write load nor reduce server count for their growing margin lending while reducing intraday trading risk in real time.

• DBS Bank (largest bank in SE Asia): Considered MongoDB but selected Aerospike in part for performance, efficiency, and architectural resilience when building their API layer to serve real-time banking apps. 

• Adtech customer: Monthly charges dropped from $30k to $5k moving from MongoDB to Aerospike while increasing throughput over 40%.

If you’re struggling to achieve what you want with MongoDB, or have experienced any of the 5 signs just discussed, why not explore what Aerospike can do for you?  Contact Aerospike to estimate TCO savings for your workload, or try Aerospike and see how you can benefit, too.