When I was designing the architecture of nderground I strongly considered using MongoDB. I purchased a couple of books and started making notes on what the design would look like.
In the end, I did not use MongoDB for nderground. I used DynamoDB. One of the core reasons that I didn’t use MongoDB involved scaling. When I was doing my research I read several accounts of people having difficulties sharding MongoDB across multiple compute engines. The problems with scaling MongoDB caused some people to either move to DynanoDB or another noSQL database like Riak.
nderground is designed to support millions of users. The advantage of DynamoDB is that it scales with only a miniscule amount of work by the user/developer. You just configure more resource by changing the resource allocation in a dialog and in a couple of minutes, you have a DynamoDB with more capacity.
nderground is a bootstrap start-up. Our engineering resources are deep, but our financial resources are shallow. We want to focus on writing software for nderground, not managing the infrastructure that supports nderground.
This is where AWS really shines. The architecture that supports nderground requires very little administrative effort.
We use a managed database, RDS/Postgres, which requires almost no administration. We use Elastic Beanstalk for our Tomcat web servers. We use SES for email. And we use DynamoDB. We have had to put zero effort (not close to zero, but zero) into managing DynamoDB. On AWS this is a huge advantage. DynamoDB is also very fast.
The use of MongoDB sometimes reminds me to herd behavior. Often people use MondoDB because others are using it. In fact, this is why I originally considered using MongoDB, so apparently I can be a herd beast too.
Before you follow the herd, I recommend thinking carefully about MongoDB’s pros and cons. Especially when it comes to scaling. This is what I did and I decided to use DynamoDB instead.