Hacker News new | ask | show | jobs
by SolutionGuy 2783 days ago
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.

1 comments

1. Managing shards and the mongos router layer should not be dubious, IMHO. Additionally - there should not be a SPOF if you've designed the architecture to leverage the native scalability aspects of MongoDB. That said, if you struggle with management, you can certainly leverage an online service that greatly simplifies not only scalability but security, manageability, and availability as well.

2. I don't know the read/write profile of your app but based on the hundreds of apps I've helped to configure and size, I'd be inclined to suggest that you don't need a Redis cache if you're configured properly.

3. Interested in that roadmap... haven't seen it... what specifically interested you?

4. MongoDB has similar available... happy to share that with you.

You're certainly free to choose whatever solution you believe works best for your use case. However, the points you've made don't appear to provide compelling arguments for Couchbase over MongoDB.

Precisely, you made my point when you acknowledged that MongoDB allows me to get a critical thing so wrong. And if I get it wrong, the pain afterwards is so intense when you go back to fixing it. Thanks.

I forgot to mention, Couchbase also guards me against the rogue DBA situation by ensuring field level encryption under application control. A huge plus.