5 real-world examples of MongoDB issues

As enterprises scale their operations and data needs grow exponentially, the choice of database technology becomes increasingly critical. What initially seemed like a good decision doesn’t always hold up as companies grow. 

While MongoDB has established itself as a popular NoSQL database, particularly favored by developers for its flexibility and ease of use, it has not always met the demands of large-scale, high-performance environments. Below, we will explore real-world examples of companies that encountered MongoDB issues and ultimately switched to different solutions that better aligned with their needs.

The issue of scaling with MongoDB

In some ways, MongoDB handles scaling well. It facilitates upgrades between tiers, enabling increased storage capacity and larger replica sets. Additionally, it offers the flexibility to scale down to a smaller replica set when needed.

However, at a server level, it’s a different story. You are advised to scale vertically, but there will be a limit to how far this can take you. Once you get beyond this, MongoDB allows you to upgrade a single replica set to a sharded configuration. However, once you have a sharded configuration, you cannot go back to a replica set; this is a strictly one-way operation.

There’s also the issue of how MongoDB handles replication. It does this through a replica set, a group of processes that maintain the same data set. While this helps with redundancy and availability, MongoDB requires one node to be the “primary” node, while other nodes are considered “secondary,” rather than treating all nodes as equivalent. That makes rebalancing more complicated. 

MongoDB experiences service interruptions while you scale up or down or adjust tiers, as this requires a replica set election, as the primary node in a replica set is removed and updated. This primary-secondary replica set model and its reliance on sharding for horizontal scaling introduce complexity and cost as data volumes increase. While MongoDB is capable of handling large datasets, scaling horizontally often requires substantial reconfiguration, leading to service interruptions and operational challenges. For many enterprises, these difficulties become more pronounced as their data requirements increase.

So now that we’re familiar with what lies behind MongoDB’s scalability issues, what does that look like in the real world? Here are some examples.

Case study: SnapDeal's struggle with performance

SnapDeal, an e-commerce platform, encountered performance issues as its data volumes grew. While MongoDB was initially suitable, response times ballooned from 5 milliseconds to more than one second under load, which was unacceptable for its real-time transaction processing needs. The inability of MongoDB to maintain low latency under high throughput led SnapDeal to seek a more performant solution.

High costs of scaling and performance trade-offs

One of MongoDB's most common pain points is the rising cost associated with scaling. As enterprises grow, the need for more hardware, often driven by the need to maintain performance because of sharding, leads to skyrocketing infrastructure expenses. Moreover, MongoDB's approach to keeping secondary indexes in DRAM for faster queries further adds to these costs. 

Case study: A top three global brokerage’s cost dilemma

A major global brokerage firm faced a dilemma when it could not deliver the low read latency required at its high write loads. To achieve the desired performance, the firm would have needed to significantly increase its server count, leading to unsustainable costs. This firm considered MongoDB but instead selected a different database solution that could deliver performance, efficiency, and architectural resilience. They found Aerospike improved performance while also moving from 150 RAM cache servers to a 10-server cluster, reducing both its capital and operational expenditures.

The complexity of MongoDB’s sharding architecture

MongoDB's sharding model, while powerful, introduces a layer of complexity that can be difficult to manage, particularly as the number of shards grows. Poor sharding strategies lead to data hot spots and inefficient data distribution, exacerbating performance issues and complicating maintenance.

Case study: MarTech’s simplified infrastructure

A customer data provider in the MarTech industry initially used MongoDB to handle its complex queries across a 9TB application. However, as the company scaled, it found that MongoDB's sharding complexities were becoming a bottleneck. Switching to an alternative database that offered simpler and more efficient scaling allowed it to achieve 5x throughput on half the hardware, significantly improving its overall operational efficiency.

Operational downtime and service interruptions

Service interruptions can occur in MongoDB during routine operations, such as scaling up or down, adjusting tiers, or when a node goes offline. That’s because the primary node in a replica set has to be removed and updated during these processes. These interruptions can disrupt business operations, especially in real-time environments.

Case study: Real-time IoT with ZoneTap

ZoneTap, a company providing sensor data for construction sites to map employees’ locations, initially used MongoDB but faced issues with service interruptions that compromised its real-time data processing needs. While the company intended to scale to thousands of safety devices, it ran into bottlenecks as early as 24 units. The unpredictable downtime led ZoneTap to switch to a database system that offered higher availability and more consistent uptime, ensuring its critical services remained uninterrupted.

Achieving cost efficiency: The AdTech industry’s switch

For companies in the AdTech industry, MongoDB’s rising costs can be particularly prohibitive. The amount of data required by that industry can reach into the petabyte range, and dozens of data retrievals may be required within 10 milliseconds or less. High server counts and expensive cloud instances make MongoDB a costly choice, especially as data sizes grow.

Case study: AdTech’s cost savings

One AdTech customer, through its partner Xenoss, was able to reduce its server count from 150 to 10 by moving away from MongoDB, reducing annual database costs from $2.5 million to $144,000. Another AdTech customer reduced its monthly charges from $30,000 to $5,000, while simultaneously increasing throughput by more than 40%.

Lessons learned from MongoDB’s limitations

These companies' experiences highlight important lessons for any enterprise evaluating its database options. While MongoDB offers many benefits, its limitations in scaling, cost, and operational complexity can make it less suitable for high-performance, large-scale environments. Companies that anticipate data growth and require consistent low latency, high availability, and predictable costs should consider alternatives better optimized for these demands.

By assessing your long-term data needs and understanding the trade-offs of database technologies, you make a more informed decision that aligns with your business objectives and ensures scalability and performance as your operations grow.