The recommended way to upgrade an existing DocumentDB cluster provisioned against the emulated 3.6 API to a newer 4.0 cluster is to use Amazon’s Database Migration Service (DMS). The documentation shows this is a complex process, which will incur application downtime.
The process involves firstly configuring change streams (and unless your database is tiny) modifying the data retention period from its default 3 hours. You then have to create your own DMS migration instance to shuttle data between the source and target cluster, configure endpoints, along with the necessary SSL and CA certificates, and then configure the migration task. DMS migrates your data only, not indexes. So you also have to manually export your indexes using a custom Amazon tool available from GitHub, and then re-import them to your new 4.0 cluster.
If all of this sounds too complex, you can use a regular mongodump and restore, but this is slow and adds performance overhead to your live cluster. Again it will incur downtime.
To upgrade to a new MongoDB version in Atlas, you simply modify the cluster from the Atlas UI or via programmatic API calls. The cluster builder will perform a rolling restart of your replica sets, automatically upgrading each node while maintaining uninterrupted application availability.
The Versioned API in MongoDB lets you future-proof your applications. Upgrade to the latest MongoDB releases without the fear of introducing backward-breaking changes that require application-side rework.
Amazon’s DocumentDB backup functionality is similar to what is available with RDS services. Users can configure a retention period of up to 35 days, with Point in Time (PiT) restores at a per-second granularity, and have the ability to specify a timeframe for the backup to start. Scheduled snapshots are incremental and the cost of backup, like all other RDS services, is included in the price of the cluster up until the current database storage size. For example, if you have a cluster with a data size of 1TB, you have 1TB of backup included. Even with incremental snapshots, this means you get 1TB snapshot for free but you have to pay for the storage needed to store the 34 subsequent incremental snapshots.
DocumentDB also offers on-demand snapshots that are manually triggered either via the AWS Console or the API. Snapshots take a full copy of the database – they are not incremental, and each counts against the backup storage quota. On-demand snapshots also do not work with PiT restores.
Snapshots can only be restored against a new cluster – you cannot restore your backup to an existing cluster.
With MongoDB Atlas, the fully managed MongoDB service, users have much more flexibility in how they schedule backups. With Continuous Backup, the user can select different retention periods for hourly, daily, weekly, and monthly backups.
Like DocumentDB, MongoDB Atlas snapshots are incremental, and support PiT restores with continuous backup, allowing users to reduce cost and improve their Recovery Time Objective. Unlike DocumentDB, MongoDB Atlas On-Demand snapshots are also incremental.
When users restore a backup in Atlas, they can apply it to an existing cluster, avoiding the time and cost needed to provision a new cluster.
The current set of security protections in DocumentDB are limited. Key gaps include the following:
RBAC is made up of a set of predefined roles that cannot be customized to specific application requirements. For example, a user can be assigned read and write privileges, but there is no way to restrict those privileges to being able to, for example, insert new data, but never modify or delete that data. Users with read/write permissions are also free to drop entire collections and indexes.
There is no support for LDAP or Active Directory authentication and authorization
Encryption at-rest can only be enabled at cluster creation time. If you create your cluster unencrypted and then want to encrypt data later, you must dump the database and then reload into a newly created cluster
DocumentDB only supports encryption with the AWS Key Management Service – there is no option for customers to bring their preferred KMS.
While DocumentDB supports event auditing, it only captures DDL operations and not DML operations, so administrators only get a partial view of database activity
MongoDB Atlas offers granular access control, full auditing, and is always fully encrypted, with integrations to AWS KMS or a customer’s own key management service.
Further enhancing data protection, with MongoDB client-side field level encryption you can selectively encrypt individual document fields, each optionally secured with its own key and decrypted seamlessly on the client. Our implementation of Field Level Encryption is totally separated from the database, making it transparent to the server, and instead handled exclusively within the MongoDB drivers on the client. All encrypted fields on the server – stored in-memory, in system logs, at-rest, and in backups – are rendered as ciphertext, making them unreadable to any party who does not have client access along with the keys necessary to decrypt the data. This is a different and more comprehensive approach than at-rest encryption offered by DocumentDB. As DocumentDB handles encryption server-side, data is still accessible to administrators who have access to the database instance itself, even if they have no client access privileges.
Effective tooling that exposes telemetry from database operations is essential to both optimizing database performance and proactively detecting emerging issues before they escalate into costly application outages. Without this telemetry, your teams can be flying blind.
DocumentDB exposes <50 metrics, compared to MongoDB Atlas with over 100 metrics. Atlas provides granular insights into individual MongoDB processes, replica sets, sharded deployments, and complete clusters, and through the Performance Advisor, provides automated and proactive guidance on how to optimize query access patterns.