Skip to Content

MongoDB vs. DocumentDB: Which Is Right for You?

Posted on October 27, 2022 by

Categories: AWS

Tags:

Are you debating between using MongoDB and DocumentDB? Choosing the best solution for your business or project might be challenging, given the recent controversy around the MongoDB license. The basic MongoDB code, according to Amazon, is challenging to grow while maintaining high availability. Amazon created its own implementation, which works with the MongoDB 3.6 API from the Apache 2.0 open-source project. Additionally, MongoDB, Inc. has revised its license to make piracy more challenging in the future. They developed a brand-new license for this purpose, the Server Side Public License.

Given the split, which option should you choose—running and scaling your instance or using DocumentDB—to host your mission-critical database? This decision becomes challenging due to the division between the firms and the lack of a clear solution.

Describe DocumentDB.

An implementation of the MongoDB 3.6 API released in January 2019 is called Amazon DocumentDB (with MongoDB compatibility). It is quick, scalable, and highly available. It is a document database that supports MongoDB workloads and is entirely managed. DocumentDB is essentially a version 3.6 clone that has been scaled up. Since it does not share or use any MongoDB source code, it is an original implementation that belongs to Amazon. The source code is sealed. For mission-critical applications that required high throughput and improved performance on significant data volumes, Amazon felt the need to develop its own solution.

They have separated storage from computation to achieve this. AAdding low latency read replicas enables the read capability to expand to millions of requests per second.

A rising number of customers having trouble running MongoDB at scale have prompted Amazon to create a solution. In Amazon’s opinion, MongoDB Atlas and other current solutions did not adequately address its customers’ issues. For instance, DocumentDB features automated data scalability, which enables effortless expansion from 10GB to 64TB. This kind of data scalability was tough before DocumentDB.

Automatic fault tolerance is another feature of the Amazon solution. Your storage volume is automatically divided into 10GB parts dispersed over many drives. Your storage volume’s 10GB blocks are duplicated six times across three availability zones. The architecture of Amazon DocumentDB allows it to tolerate the loss of up to two copies of data without impairing write availability and up to three copies without impairing read availability. Additionally, it has self-healing storage space. Disks and data blocks are automatically checked for faults constantly.

You are protected for the majority of compliance since Amazon hosts the service. Among the various standards that DocumentDB conforms with are PCI DSS, ISO 9001, 27001, 27017, 27017, SOC 1, SOC 2, SOC 3, and HIPAA eligibility.

That Is Wonderful! Is There a Catch?

DocumentDB simulates the queries and answers a MongoDB client anticipates being consistent with the 3.6 API. Theoretically, any driver that is appropriate for 3.4+ will function. However, several restrictions apply to this assertion that is not included in Amazon’s promotional materials. Consider both the vital functional differences and the gaps in the API support.

Amazon reportedly failed 61% of its accuracy tests, according to MongoDB. Among the most significant disparities to take into account:

Operators in query languages and phases of the aggregation process are heavily constrained. Only 50% were supported at the time this article was being written. MapReduce, for instance, is not supported. This is more likely problematic when working with more extensive data sets. Here is a list of all the aggregate features.

There are constraints on several data types and indexes. Case-insensitive indices and the Decimal128 datatype are not supported.

There is no support for change streams. This functionality would likely be useful for large-scale applications. Given their implementation, it’s uncertain if this functionality will end up in DocumentDB. Before utilizing DocumentDB, be sure to verify your code for any instances of change streams. This Java code, for instance, will not work:

MongoCursor<ChangeStreamDocument<Document>> View rawcursor.java is hosted on GitHub with the following code: cursor = inventory.watch().iterator(); ChangeStreamDocumentDocument> next = cursor.next();

Another difficulty is tunable consistency. It’s doubtful that you will be able to dictate how consistency is handled for your database instance because DocumentDB is fundamentally different and is focused on scalability. Users must adjust if Amazon decides to modify how consistency assurances are implemented since they are at Amazon’s mercy.

Before selecting a choice, comprehend the list of compatibility problems presented below. According to their statement, most of the 3.6 API will still be supported by Amazon, although they have not said when they will stop doing so. You can end up having to wait an extended period for essential features.

Being limited to DocumentDB version 3.6 is its main drawback. What will happen to DocumentDB in the future is unknown due to the disagreement between MongoDB and Amazon and the new license structure.

MongoDB intends to oppose Amazon’s implementation since it does not support it. MongoDB is now a substantial version ahead (4.0+), with some excellent new capabilities being published that are not provided by DocumentDB because Amazon has not made any intentions to support more recent versions. Whether Amazon will develop a new API that departs from MongoDB’s mainline. Users would then be forced to utilize a cumbersome derivative version.

MongoDB that only Amazon supported. The alternative is perperpetually utilizesentDB 3.6, preventing customers from using excellent new MongoDB capabilities. DocumentDB might result in unwanted vendor lock-in and a challenging future migration back to MongoDB. Amazon has not yet responded on this, so time will tell how things turn out.

Multi-statement ACID transactions are one excellent feature added to MongoDB in version 4.0; DocumentDB is not likely to enable this, especially with its distributed architecture that divides storage and computation. For instance, the following Java code will crash on DocumentDB: