I posted my problems with it as a response to a sibling comment. Since this was four or five years ago now, maybe all of this has been fixed, but that's not something I'm going to depend on in production any time soon.

Also, the MongoDB users you list must be taken with a grain of salt. For example, you list Facebook on that page. Nope. The description is "...adapted the storage engine API, extending MongoDB into new workloads and new capabilities." That is, Facebook acquired Parse, which used Mongo. Facebook ported MongoDB to run on RocksDB. Facebook shut down Parse. End of MongoDB at Facebook. You list Google, and the mouseover is basically that you can run MongoDB on GCE. I'm not saying that Mongo is unusual in this behavior. It's how most people listing "who uses X" build their lists.

It's been four years since I looked at it, but WiredTiger didn't replicate atomically under high write rates.

We had a master and replica running on the same machine and we were doing packet capture and inspection writing to the database. Our capture pipeline wrote to the master, and our system queried the replica so we didn't destroy the write rate. We were doing a zero allocation capture pipeline where the pages that the kernel passed back to us were already embedded in the skeleton of a BSON document that we then filled in and finally shoved straight onto the wire to the local Mongo master.

We started seeing records in the replica that were missing fields that were present on the master. These weren't eventual consistency things. Records are supposed to be replicated atomically, and these persisted in the system. We ended up having to run full database scans to find and clean them up.

Mongo claimed they fixed it twice. In neither case was it fixed. We migrated to a different system at that point. Maybe it's all wonderful now, but since MongoDB was a pain to use for other reasons, I have never felt the slightest inclination go back and try it again.