Item: MongoDB
Rating: 9
Author: Eric Mason

Use Cases and Deployment Scope

We use MongoDB at the heart of our application where speed and consistency are critical. It's used primarily by the engineering backend team and vicariously by other teams using parts of the product. It gives us the means to quickly iterate our data models with fewer painful migrations than we'd have with a traditional RDBMS and its JSON-like BSON object modeling maps nicely to our APIs.

Pros and Cons

The BSON-based document storage models allow for sophisticated data modeling.
Flexible MongoDB collection schemas allow for the storage of polymorphic records and easy migrations.
MongoDB has readily adopted popular database concepts like change streams and graph queries.

MongoDB will start to struggle with very large datasets even when well-indexed.
Complex aggregation queries can be tricky in MongoDB when compared with an SQL-based database.
Scaling a Mongo database can be expensive.

Return on Investment

MongoDB reduced development time spent on risky database migration for minor iterations.
MongoDB has reduced the amount of time we need to spend on database maintenance.
If it has cost us in terms of ROI, it would be in some of the complexity that's been involved in joining different pieces of data across collections, but that's been somewhat mitigated with GraphQL.

Alternatives Considered

MySQL and Amazon DynamoDB

In our early development days we weighed NoSQL databases like MongoDB with RDBMS solutions like MySQL. We were more familiar with MySQL from past experience but also were wary of painful data migrations that slowed down development iterations and increased the risk of outages during deployments. We also evaluated raw key-value document stores like DynamicDB, but we found those to be severely limited when compared to the functionality you'd get with an RDBMS. MongoDB provided a nice middle-ground, supporting many of the nice querying and indexing features you'd get from an RDBMS, but with the flexible model convenience of a key-value store.

Other Software Used

Google Cloud Datastore, Redis, Node

Likelihood to Renew

We're likely to continue using MongoDB for several reasons. On one hand, we've invested heavily in this database and it would be a painful costly process to translate our complex set of models to an alternative. On the other hand, we continue to be happy with MongoDB for its reliability and the pace at which this tool has evolved. We have confidence in MongoDB's ability to evolve and improve going forward.

Likelihood to Recommend

Scenarios where MongoDB is well suited:
- When working with small/medium-sized dataset where speed and flexibility are priorities.
- When working with schema-less or polymorphic models that would be much harder to represent in a traditional RDBMS.
- More generally MongoDB makes sense as a place you'd store your business logic/frequently accessed data, not as storage for infrequently accessed long-term storage.

Scenarios where MongoDB is less appropriate:
- I wouldn't recommend using MongoDB as a caching service. It's more expensive than many databases that could be used where performance isn't a critical issue or long-term persistence is desired (e.g., compared with Datastore/Firestore/Dynamo/etc.), while it falls short of Redis when performance is critical or data need not be stored for long.

MongoDB, a flexible/reliable DB that will draw you to the NoSQL world.

Overall Satisfaction with MongoDB