Backend for extremely large-scale, cloud-based systems.

MongoDB focuses on enterprise solutions with high configurability and a high degree of flexibility, aiming to provide an answer to almost any scenario.

The drawback of this approach is that to operate a MongoDB database properly, you need a high degree of dedicated expertise to achieve good results.

For that reason, MongoDB recommends MongoDB Atlas (the cloud-hosted version) instead of running MongoDB directly.

db.Orders.find({
    "ShipTo.City": "London"
})

MongoDB queries are using a JSON-based format specific to the database. You'll need to familiarize yourself with the language to effectively use MongoDB.

db.Orders.createIndex({
    "ShipTo.City": 1
})

Requires careful index management for good performance.

With MongoDB, it is the responsibility of the developers (or database administrators) to create the right set of indexes for the queries.

This is a delicate and complex task that requires deep insight into both the system and the database internals. Without careful attention to detail, it is easy to end up with very slow queries.

Fixing these sorts of issues can be costly and complicated.

db.Orders.find({
    "ShipTo.City": "London"
}).sort({ "OrderedAt": -1})
.limit(10)

Some assembly required

db.Orders.createIndex({
    "ShipTo.City": 1,
    "OrderedAt": -1
})

db.Orders.aggregate([{
    "$group": {
        "_id": "$ShipTo.City",
        "Count": { "$sum": 1 }
    }
},
{  "$sort": { "Count": -1 }  },
    {
        "$project": {
            "City": "$_id",
            "Count": 1,
            "_id": 0
    }
}])

In MongoDB, this query runtime is proportional to the amount of records, even if you have the appropriate index.

The more Orders you have, the more costly this query is.

Indexes in MongoDB are processed as part of the document write operation. The more indexes you have, the slower your write performance becomes. On the other hand, without an appropriate index, your queries will suffer.

MongoDB has a limit of up to 64 indexes per collection. That is a hard limit, regardless of the system resources. Hitting this limit means that you need to re-think your entire persistence strategy.

Managing the right indexes in MongoDB is a complex process, balancing query speed vs. write performance and requiring detailed knowledge of the internals of the database engine.

db.Employees.find()
.sort({ LastName: 1,
FirstName: 1 })

db.Employees.find()
.sort({ LastName: -1,
FirstName: 1 })

db.Employees.find()
.sort({ LastName: 1, FirstName: 1 })

db.Employees.find()
.sort({ LastName: -1, FirstName: 1 })

MongoDB will need two separate indexes to answer those queries efficiently, doubling the cost of writes.

db.Employees.createIndex({
LastName: 1, FirstName: 1 })

db.Employees.createIndex({
LastName: -1, FirstName: 1 })

MongoDB offers a wide variety of authentication and authorization integrations. However, you need to opt in for any of these, as by default, MongoDB will run without any authentication whatsoever. See:  How to lose your data in 3 steps

It's easy to end up in situations where your production database is completely open to the whole wide world. Ransomware attacks targeting MongoDB have affected tens of thousands of instances, and any public instance is attacked within minutes.

Setting up MongoDB securely requires reading a 100+ page document and properly following all recommendations. The proper procedure is complex and error-prone, leading to many instances remaining unprotected and potential data loss.

MongoDB uses the single primary and multiple secondary nodes model. Read operations can be distributed across the cluster, but writes must be directed to the single primary node.

A MongoDB cluster is composed of many distinct components (config servers, query routers, and shards). Each one needs to be deployed and configured separately.

MongoDB write scaling requires moving to a sharded approach as soon as your database approaches the 200 GB mark, which is far earlier than with RavenDB.

Primary node failure means downtime for writes for a long duration (more than 10 sec by default). In some conditions, recovery from the failure will take much longer.

By default, reads from the cluster fail if the primary node is down. You need to specify the appropriate readConcern setting on the call for read failover to work.

Proper failover handling requires cooperation from both the database administrators and developers and necessitates careful testing to ensure high availability with MongoDB.

// not possible, you need to write
// a full blown program for this

MongoDB's update capabilities are limited to the updateMany() call, which can update multiple documents in one call.

Such a method does not allow you to make changes to each document based on its own data, but only set properties to the same value across all documents.

A migration operation such as unifying FirstName and LastName intoName requires writing code to load the documents into your process, modify them, and save them back.

MongoDB requires a significant amount of complexity to run successfully in production. The assumption is that the database is being run by a team that is very familiar with how it works.

MongoDB leaves caching and cache management completely at the hands of the user. You are expected to use a 3rd party tool or roll your own if you need the performance boost from the cache.

MongoDB has transaction support since 2019, but as an opt-in feature. By default, it may persist partial data. Full Text Search requires either integrating with Elasticsearch. Such integration requires additional setup, synchronization, and maintenance.

MongoDB relies heavily on indexes for query performance. Administrators must manually analyze query patterns, create appropriate indexes, and periodically optimize them.

Incorrect indexing can lead to performance bottlenecks.