Amazon claims that migrating from MongoDB to DocumentDB is “as easy as changing the database endpoint to the new Amazon DocumentDB cluster.”
We regularly assess DocumentDB's compatibility claims by running six MongoDB test suites against DocumentDB's API emulation. These suites are the best representation of the full MongoDB API. They are used to test MongoDB's conformity and correctness on every database release.
The tests comprise database commands, CRUD operations, aggregations, multi-document ACID transactions, correct behavior of the decimal data type, change streams, and data governance controls.
Test results
The tests indicate that DocumentDB misses functionality compared to MongoDB. For developers, this means:
- Any existing MongoDB apps relying on this functionality would need to be re-engineered if they are to be migrated to DocumentDB.
- Any new apps written against the DocumentDB API only support a subset of MongoDB's functionality.
- Any application written for DocumentDB will be locked in to AWS.
In terms of functionality, DocumentDB most closely resembles MongoDB 4.0, released in 2018. As a result, developers will need to do one of the following:
- Reimplement required database functionality back in the application tier, slowing down the pace of application development
- Move multiple copies of the data into adjacent AWS technologies, with the associated increases in development and operational costs, and platform complexity
Key gaps include:
- Limited support for MongoDB Query Language
- Limited aggregation pipeline stages and query language operators
Missing functionality includes:
- No graph traversals and no faceting or bucketing of data
- Limited number of arithmetic, array, and set operators available
- No on-demand materialized views
- No way to use aggregation expressions with the query language
- No support for type conversions in the aggregation pipeline (which allow you to run sophisticated data transformations natively in the database, eliminating many costly, slow, and fragile ETL processes)
- Aggregation pipeline stages and operators added in recent MongoDB releases—including regex, timestamps, trigonometry, merge, custom aggregation expressions, union, and more—are not available
- No schema governance to control data quality
Despite claiming support for change streams, DocumentDB:
- Does not support change streams being opened against a non-primary node. Without sharding support, all of the application's writes also have to be serviced by that single DocumentDB primary node, so adding change streams will incur potentially significant contention, impacting application throughput and latency.
- Does not support DDL events, including drop, rename, and dropDatabase, preventing developers from responding to collection- and database-level changes.
- Does not support $replaceWith, $set, or $unset aggregation pipelines, limiting the ability to filter or modify change stream output.
- Does not support Resume_after operator, limiting the ability for users to transition apps between MongoDB and DocumentDB.
- Has no ability to set fine-grained, per-user permissions for change streams. If change streams are enabled on a database, any and all users with read permissions can see all changes on the database.
- Only stores change events for a default of three hours before being dropped. MongoDB can deliver change events until the oplog rolls over, with no hard limit.
- Will incur additional charges by change streams for storing and delivering the changes. Change streams in MongoDB Atlas have no additional cost.
- Does not support on-demand materialized views.
- Only supports limited cursor options: no collation, or tailable cursors.
- Does not support causal consistency guarantees, reducing data quality by eliminating the ability to perform monotonic reads across replicas.
- Does not implement the MongoDB API's tunable consistency options. Even in cases that call for higher throughput and reduced durability guarantees, like streaming IoT sensor data, user tracking, or large-scale social media platforms, clients must wait for all writes to reach a majority of those nodes.
DocumentDB's multi-document ACID transactions support, added in the 4.0 update, is limited when compared to transactions in MongoDB:
- DocumentDB transactions can be indeterminate and “ambiguous.”
- Transactions that are affected by a timeout or node failure will return an error that cannot tell the user whether the transaction succeeded or failed, potentially violating data integrity and ACID guarantees. To avoid this “ambiguity,” Amazon's documentation recommends users rewrite their code to make all updates idempotent, consuming precious development resources.
- Transactions cannot process more than 32MB of data.
- ACID transactions are scoped to run against collections on a single primary node only, limiting scalability.
- DocumentDB does not support retryable writes or commits, meaning developers must develop complex error-handling code themselves.
MongoDB Atlas: Always fully featured
In contrast, Atlas is updated as soon as each new database release is declared as generally available (GA), meaning developers don't have to wait months or years to access the latest platform enhancements. MongoDB 5.0 was the first to offer the Stable API, which allows users to pin their application to a specific version of the MongoDB API. This gives them the confidence that their code will continue to run uninterrupted for years, even as the database is upgraded beneath it. The Stable API provides you with a level of investment protection and API stability that is simply not possible with most other databases, including DocumentDB.
The service is backed by thousands of support engineers, consultants, and solutions architects from MongoDB and the partner ecosystem, which offers the benefits of collective MongoDB knowledge acquired by supporting tens of thousands of MongoDB customers over the past decade.
Safe Harbor
The development, release, and timing of any features or functionality described for our products remain at our sole discretion. This information is merely intended to outline our general product direction, and it should not be relied on in making a purchasing decision, nor is this a commitment, promise, or legal obligation to deliver any material, code, or functionality.