

If you send a massive volume of queries at it, it will try to do its best to answer the requests, slowly strangling your application and annoying your users. MongoDB doesn’t strictly enforce query rate or complexity limits. MongoDB has a well-respected hosted offering, Atlas, that will soon become the majority of the company’s revenue. You can run MongoDB anywhere: your laptop, continuous integration environment, and even your overly-complex Kubernetes cluster that is destroying the productivity of your engineering organization. You can query any attribute in a document. There are more data types available, and it’s good at working with geospatial data.

With that out of the way, let’s start the competition. But making your production environment more complex because of one project is usually a bad idea. Introducing new technologies can look great on resumes. If you need to choose between them because of concerns around scale, the next best answer is this: Use the one you’re already successfully using. The default answer when considering which of DynamoDB or MongoDB to use is to use neither.īuilding a service using a relational database is a better-understood pattern they’re a lot easier to hire expertise for and Google for solutions when you get stuck. This article compares the two databases in areas that matter, and chooses an overall winner because that makes these comparisons exciting! Actually, don’t compare them Most technology comparison guides compare a bunch of launch features and don’t look at the real-world use of both. These systems tend to outperform relational databases solving scaling problems. The primary use case for both is storing and querying data stored in “documents”-not Word documents that real people use, but lumps of JSON passed back and forth by computers serving sites like. DynamoDB and MongoDB are both wildly successful modern replacements for traditional database systems, such as MySQL and PostgreSQL (and maybe even Route53!).
