I actually evaluated MongoDB before I decided to go with Couchbase. Mainly because of the following reasons. 1. It was a pain to manage the shards and the 'mongos' processes would be hotspots and SPOFs in the system. No wonder there were ways around it, but Couchbase did it right. With Couchbase, sharding was maintenance free and the client was aware of the cluster topology and which shards lived where. Rebalancing was a breeze and you could even pause and resume it if required.

2. We didn't want to introduce MongoDB and then having to setup a separate cache like Redis in the front. That would be too many moving parts. With Couchbase we got a built in cache that was managed as part of the solution, a huge plus point for us.

3. Couchbase offered a great road map, at the time we ran the evaluation N1QL wasn't GA yet, but it offered great promise and look where it has come today.

4. The official Kuberbetes operator offers a great way to run and scale Couchbase on any public or private cloud. It encompasses a lot of operational knowledge about the product and is a massive plus.

4. The cluster management for Couchbase is totally based on a REST API that is open. The standard web UI makes use of it too. The REST API offers the best way to automate administrative tasks and allows you to create your own customized monitoring arrangements.

So, above is a brief roundup of why we made an educated decision not to use MongoDB in favor of Couchbase.