Amazon DocumentDB (with MongoDB compatibility) FAQs

Amazon DocumentDB (with MongoDB compatibility) is a fast, scalable, highly available, and fully managed document database service that supports MongoDB workloads. Developers can use the same MongoDB application code, drivers, and tools as they do today to run, manage, and scale workloads on Amazon DocumentDB and enjoy improved performance, scalability, and availability without having to worry about managing the underlying infrastructure. Customers can use Amazon Database Migration Service (DMS) for free (for six months) to easily migrate their on-premises or Amazon Elastic Compute Cloud (EC2) MongoDB databases to Amazon DocumentDB with virtually no downtime. There are no up-front investments required to use Amazon DocumentDB, and customers only pay for the capacity they use.

It means that a vast majority of the applications, drivers, and tools you already use today with your MongoDB database can be used with Amazon DocumentDB with little or no change. Amazon DocumentDB emulates the responses that a client expects from a MongoDB server by implementing the Apache 2.0 open source MongoDB 3.6 and 4.0 APIs on a purpose-built, distributed, fault-tolerant, self-healing storage system that gives customers the performance, scalability, and availability they need when operating mission-critical MongoDB workloads at scale. Learn more about supported MongoDB APIs.

Amazon DocumentDB emulates the responses that a client expects from a MongoDB server by implementing the Apache 2.0 open source MongoDB 3.6 and 4.0 APIs on a purpose-built, distributed, fault-tolerant, self-healing storage system that gives customers the performance, scalability, and availability they need when operating mission-critical MongoDB workloads at scale.

Customers can use Amazon Database Migration Service (DMS) for free (for six months) to easily migrate their on-premises or Amazon Elastic Compute Cloud (EC2) MongoDB databases to Amazon DocumentDB with virtually no downtime. With DMS, you can migration from a MongoDB replica set or from a sharded cluster to Amazon DocumentDB. Additionally, you can use most existing tools to migrate data from a MongoDB database to Amazon DocumentDB, including mongodump/mongorestore, mongoexport/mongoimport, and third-party tools that support Change Data Capture via the oplog. For more information, see Migrating to Amazon DocumentDB.

No, Amazon DocumentDB works with a vast majority of MongoDB drivers compatible with MongoDB 3.4+.

Amazon DocumentDB clusters are deployed within a customer's Amazon VPC and can be accessed directly by EC2 instances or other Amazon Web Services services that are deployed in the same VPC. Additionally, Amazon DocumentDB can be accessed by EC2 instances or other Amazon Web Services services in different VPCs in the same region or other regions via VPC peering. Access to Amazon DocumentDB clusters must be done through the mongo shell or with MongoDB drivers. Amazon DocumentDB requires that you authenticate when connecting to a cluster. For additional options, see Connecting to an Amazon DocumentDB Cluster from Outside an Amazon VPC.

For certain management features such as instance lifecycle management, encryption-at-rest with Amazon Key Management Service (KMS) keys and security groups management, Amazon DocumentDB leverages operational technology that is shared with Amazon RDS.

Please see the Amazon DocumentDB pricing page for current information on available instant types per region.

Yes. For more information, please see Amazon DocumentDB (with MongoDB compatibility) Service Level Agreement.

When writing to storage, Amazon DocumentDB only persists a write-ahead logs, and does not need to write full buffer page syncs. As a result of this optimization, which does not compromise durability, Amazon DocumentDB writes are typically faster than traditional databases. Amazon DocumentDB clusters can scale out to millions of reads per second with up to 15-read replicas.

Please see the Amazon DocumentDB pricing page for current pricing information.

Please see the Amazon DocumentDB pricing page for current information on regions and prices.

No, Amazon DocumentDB does not have a free tier.

No. Amazon DocumentDB’s storage replication feature is included in the price. You are charged based on the size of the data in your cluster and you are not charged separately for the replicated storage.

IOs are input/output operations performed by Amazon DocumentDB against an SSD-based virtualized storage layer. Every database page read operation counts as one IO. Amazon DocumentDB issues reads against the storage layer in order to fetch pages not present in the buffer cache. Each page is 8KB in Amazon DocumentDB.

Amazon DocumentDB was designed to eliminate unnecessary IO operations in order to reduce costs and to ensure resources are available for serving read/write traffic. Write IOs are only consumed when pushing write-ahead log records to the storage layer for the purpose of making writes durable. Write IOs are counted in 4KB units. For example, a log record that is 1KB will count as one IO operation. However, concurrent write operations whose write-ahead log is less than 4KB can be batched together by the Amazon DocumentDB cloud database engine in order to optimize I/O consumption. Unlike traditional database engines Amazon DocumentDB never pushes modified database pages to the storage layer, resulting in further IO consumption savings. 

You can see how many IOs your Amazon DocumentDB cluster is consuming by going to the Amazon Web Services Console. To find your IO consumption, go to the Amazon DocumentDB section of the console, look at your list of clusters, select your Amazon DocumentDB cluster, then look for the “VolumeReadIOPs” and “VolumeWriteIOPs” metrics in the monitoring section.

Instance pricing is calculated from the time the instance is created to the time the instance is deleted. Instances are billed in one second increments, with a 10 minute minimum charge following a billable status change such as creating, modifying, or deleting an instance.

As an example, if you create an r5.large instance at 1:00:00 PM, modify the instance to an r5.xlarge at 1:30:00 PM and delete the instance at 1:50:00 PM, you will be charged for 1,800 seconds (30 minutes) at r5.large pricing and 1,200 seconds (20 minutes) at r5.xlarge prices. If you create an r5.large instance at 3:00:00 PM and delete it at 3:06:00PM, the 10 minute minimum applies, and you will be charged for 600 seconds (10 minutes) at r5.large pricing.

Amazon DocumentDB I/O-Optimized is the ideal choice when you need predictable costs or have I/O intensive applications. If you expect your I/O costs to exceed 25% of your total Amazon DocumentDB database costs, this option offers enhanced price performance. 

You can use the one-click experience available in the Amazon Web Services Management Console to change the storage configuration of your existing database clusters to be I/O-Optimized. You can also invoke the Amazon Web Services Command Line Interface or Amazon Web Services Software Development Kit to make this change. 

You can switch your existing database clusters once every 30 days to Amazon DocumentDB I/O-Optimized. You can switch back to Amazon DocumentDB Standard at any time.

Amazon DocumentDB 5.0. supports Amazon DocumentDB I/O-Optimized storage configuration.

There are no changes to the price of snapshot or continuous backup with the Amazon DocumentDB I/O-Optimized. 

Yes, the charges for the I/O operations required to replicate data across regions continue to apply. Amazon DocumentDB I/O-Optimized does not charge for read and write I/O operations, which is different from data replication. 

The minimum storage is 10GB. Based on your cluster usage, your Amazon DocumentDB storage will automatically grow, up to 64 TB in 10GB increments with no impact on performance. There is no need to provision storage in advance.

Amazon DocumentDB scales in two dimensions: storage and compute. Amazon DocumentDB's storage automatically scales from 10GB to 64 TB in increments of 10GB. Amazon DocumentDB's compute capacity can be scaled up by creating larger instances and horizontally (for greater read throughput) by adding additional replica instances (up to 15) to the cluster.

You can scale the compute resources allocated to your instance in the Amazon Web Services Management Console by selecting the desired instance and clicking the “modify” button. Memory and CPU resources are modified by changing your instance class.

When you modify your instance class, your requested changes will be applied during your specified maintenance window. Alternatively, you can use the "Apply Immediately" flag to apply your scaling requests immediately. Both of these options will have an availability impact for a few minutes as the scaling operation is performed. Bear in mind that any other pending system changes will also be applied.

No. Amazon DocumentDB's distributed storage architecture is a different approach to scaling than MongoDB sharding.

Automated backups are always enabled on Amazon DocumentDB clusters. Amazon DocumentDB’s simple database backup capability enables point-in-time recovery for your clusters. You can increase your backup window for point-in-time restores up to 35-days. Backups do not impact database performance.

Yes. Manual snapshots can be retained beyond the backup window and there is no performance impact when taking snapshots. Note that restoring data from cluster snapshots requires creating a new cluster.

Amazon DocumentDB automatically maintains six copies of your data across three Availability Zones and will automatically attempt to recover your instance in a healthy AZ with no data loss. In the unlikely event your data is unavailable within Amazon DocumentDB storage, you can restore from a cluster snapshot or perform a point-in-time restore operation to a new cluster. Note that the latest restorable time for a point-in-time restore operation can be up to five minutes in the past.

You can choose to create a final snapshot when deleting your instance. If you do, you can use this snapshot to restore the deleted instance at a later date. Amazon DocumentDB retains this final user-created snapshot along with all other manually created snapshots after the instance is deleted. Only snapshots are retained after the instance is deleted (i.e., automated backups created for point-in-time restore are not kept).

Deleting your Amazon Web Services account will delete all automated backups and snapshot backups contained in the account.

Yes. Amazon DocumentDB gives you the ability to create snapshots of your cluster, which you can use later to restore a cluster. You can share a snapshot with a different Amazon Web Services account, and the owner of the recipient account can use your snapshot to restore a cluster that contains your data. You can even choose to make your snapshots public – that is, anybody can restore a cluster containing your (public) data. You can use this feature to share data between your various environments (production, dev/test, staging, etc.) that have different Amazon Web Services accounts, as well as keep backups of all your data secure in a separate account in case your main Amazon Web Services account is ever compromised.

There is no charge for sharing snapshots between accounts. However, you may be charged for the snapshots themselves, as well as any clusters that you restore from shared snapshots.

We do not support sharing automatic cluster snapshots. To share an automatic snapshot, you must manually create a copy of the snapshot, and then share the copy.

No. Your shared Amazon DocumentDB snapshots will only be accessible by accounts in the same region as the account that shares them.

Yes. You can share encrypted Amazon DocumentDB snapshots. The recipient of the shared snapshot must have access to the KMS key that was used to encrypt the snapshot.

No. Amazon DocumentDB snapshots can only be used inside of the service.

You can choose to create a final snapshot when deleting your cluster. If you do, you can use this snapshot to restore the deleted cluster at a later date. Amazon DocumentDB retains this final user-created snapshot along with all other manually created snapshots after the cluster is deleted.

Amazon DocumentDB automatically divides your storage volume into 10GB segments spread across many disks. Each 10GB chunk of your storage volume is replicated six ways, across three Availability Zones. Amazon DocumentDB is designed to transparently handle the loss of up to two copies of data without affecting write availability and up to three copies without affecting read availability. Amazon DocumentDB’s storage volume is also self-healing. Data blocks and disks are continuously scanned for errors and repaired automatically.

Unlike other databases, after a database crash Amazon DocumentDB does not need to replay the redo log from the last database checkpoint (typically 5 minutes) and confirm that all changes have been applied, before making the database available for operations. This reduces database restart times to less than 60 seconds in most cases. Amazon DocumentDB moves the cache out of the database process and makes it available immediately at restart time. This prevents you from having to throttle access until the cache is repopulated to avoid brownouts.

Amazon DocumentDB supports read replicas, which share the same underlying storage volume as the primary instance. Updates made by the primary instance are visible to all Amazon DocumentDB replicas.

Feature: Amazon DocumentDB read replicas

Number of replicas: Up to 15

Replication Type: Asynchronous (typically milliseconds)

Performance impact on primary: Low

Act as failover target: Yes (no data loss)

Automated failover: Yes

No. Amazon DocumentDB does not support cross-region replicas.

Yes. You can assign a promotion priority tier to each instance on your cluster. If the primary instance fails, Amazon DocumentDB will promote the replica with the highest priority to primary. If there are inconsistencies between two or more replicas in the same priority tier, then Amazon DocumentDB will promote the replica that is the same size as the primary instance.

You can modify the priority tier for an instance at any time. Simply modifying priority tiers will not trigger a failover.

You can assign lower priority tiers to replicas that you do not want promoted to the primary instance. However, if the higher priority replicas on the cluster are unhealthy or unavailable for some reason, then Amazon DocumentDB will promote the lower priority replica.

Amazon DocumentDB can be deployed in a high-availability configuration by using replica instances in multiple Amazon Web Services Availability Zones as failover targets. In the event of a primary instance failure, a replica instance is automatically promoted to be the new primary with minimal service interruption.

You can add additional Amazon DocumentDB replicas. Amazon DocumentDB replicas share the same underlying storage as the primary instance. Any Amazon DocumentDB replica can be promoted to become primary without any data loss and therefore can be used for enhancing fault tolerance in the event of a primary instance failure. To increase cluster availability, simply create 1 to 15 replicas, in multiple AZs, and Amazon DocumentDB will automatically include them in failover primary selection in the event of an instance outage.

Failover is automatically handled by Amazon DocumentDB so that your applications can resume database operations as quickly as possible without manual administrative intervention.

• If you have an Amazon DocumentDB replica instance in the same or a different Availability Zone, when failing over, Amazon DocumentDB flips the canonical name record (CNAME) for your instance to point at the healthy replica, which is in turn promoted to become the new primary. Start-to-finish, failover typically completes within 30 seconds.

• If you do not have an Amazon DocumentDB replica instance (i.e. a single instance cluster), Amazon DocumentDB will attempt to create a new instance in the same Availability Zone as the original instance. This replacement of the original instance is done on a best-effort basis and may not succeed, for example, if there is an issue that is broadly affecting the Availability Zone.

Your application should retry database connections in the event of connection loss.

Amazon DocumentDB will automatically detect a problem with your primary instance and begin routing your read/write traffic to an Amazon DocumentDB replica instance. On average, this failover will complete within 30 seconds. In addition, the read traffic that your Amazon DocumentDB replicas instances were serving will be briefly interrupted.

Since Amazon DocumentDB replicas share the same data volume as the primary instance, there is virtually no replication lag. We typically observe lag times in the 10s of milliseconds.

Yes. All Amazon DocumentDB clusters must be created in a VPC. With Amazon VPC, you can define a virtual network topology that closely resembles a traditional network that you might operate in your own datacenter. This gives you complete control over who can access your Amazon DocumentDB clusters.

Amazon DocumentDB utilizes VPC’s strict network and authorization boundary. Authentication and authorization for Amazon DocumentDB management APIs is provided by IAM users, roles, and policies. Authentication to an Amazon DocumentDB database is done via standard MongoDB tools and drivers with Salted Challenge Response Authentication Mechanism (SCRAM), the default authentication mechanism for MongoDB.

Yes. Amazon DocumentDB allows you to encrypt your clusters using keys you manage through Amazon Key Management Service (KMS). On a cluster running with Amazon DocumentDB encryption, data stored at rest in the underlying storage is encrypted, as are its automated backups, snapshots, and replicas in the same cluster. Encryption and decryption are handled seamlessly. For more information about the use of KMS with Amazon DocumentDB, see the Encrypting Amazon DocumentDB Data at Rest.

Currently, encrypting an existing unencrypted Amazon DocumentDB cluster is not supported. To use Amazon DocumentDB encryption for an existing unencrypted cluster, create a new cluster with encryption enabled and migrate your data into it.

The In-place major version upgrade (MVU) lets you upgrade Amazon DocumentDB 3.6 or 4.0 clusters to Amazon DocumentDB 5.0 using the Amazon Web Services Console, Software Development Kit (SDK), or Command Line Interface (CLI). With in-place MVU, there is no need to create new clusters or change your end points. In-place MVU is available in Amazon Web Services China (Beijing) Region, operated by Sinnet and in Amazon Web Services China (Ningxia) Region, operated by NWCD. To get started with in-place MVU, please review in-place MVU documentation.

In-place MVU lets you seamlessly upgrade your Amazon DocumentDB 3.6 or 4.0 clusters to version 5.0 without the need to perform backup and restore to another cluster and without using other data migration tools. In doing so, it reduces the time and effort associated with usual upgrade process which entail configuring the source and target end points, migrating indexes and data, changing application code, etc. You won't need to change your end-point in your applications post upgrade. Since the data stays in the same cluster, there is no additional cost to upgrade using feature. 

Downtime can vary from cluster to cluster depending on number of collections, indexes, databases, and instances. Before running in-place major version upgrade on your production cluster, we strongly recommend running it in a lower environment to test downtime, performance, and also verify that your applications work as expected post upgrade. You can also utilize Amazon DocumentDB’s fast clone feature to clone your cluster data for testing. Depending on the complexity of your Amazon DocumentDB implementation, you can engage our database solutions architect for additional help.

In-place MVU is only supported with Amazon DocumentDB 3.6 or 4.0 as a source and version 5.0 as target. It is not supported for Amazon DocumentDB Global Clusters or Elastic Clusters or with Amazon DocumentDB 4.0 as target. 

Vector search is a method used in machine learning to find similar data points to a given data point by comparing their vector representations using distance or similarity metrics. The closer the two vectors are in the vector space, the more similar the underlying items are considered to be. This technique helps capture the meaning or semantics of the data. This approach is useful in various applications, such as recommendation systems, natural language processing, and image recognition. 

Vector search for Amazon DocumentDB combines the flexibility and rich querying capability of a JSON-based document database with the power of vector search. If you want to use your existing Amazon DocumentDB data or a flexible document data structure to build machine learning and generative AI use cases such as semantic search experience, product recommendation, personalization, chatbots, fraud detection, and anomaly detection, then vector search for Amazon DocumentDB would be an ideal choice. 

Vector search for Amazon DocumentDB is available on  Amazon DocumentDB 5.0 instance-based clusters.

Semantic search using Vector search for Amazon DocumentDB captures the meaning, context, and intent behind the data, whereas a keyword search finds document based on the actual text or any pre-defined synonym mappings. For example, in a traditional e-commerce application, a green dress might return products that have words “green” and “dress” in their descriptions. But, with Vector search for Amazon DocumentDB backed semantic search, the application will understand the user’s actual intent. It will retrieve results with dresses in different shades of green.

No. Vector search for Amazon DocumentDB is available to all Amazon DocumentDB customers using DocumentDB 5.0 at no additional cost. Standard compute, I/O, storage, and backup charges will apply as you store, index, and search vector embeddings in Amazon DocumentDB.