DynamoDB vs DocumentDB - The Ultimate Comparison
Written by Lakindu Hewawasam
Published on May 23rd, 2022
Time to 10x your DynamoDB productivity with Dynobase [learn more]
Amazon DynamoDB and Amazon DocumentDB are 2 of Amazon's most popular cloud-based NoSQL database solutions. However, both services have some unique features, and it is essential to understand the similarities and differences between these services to determine the most suitable NoSQL database service for your application.
Therefore, this article will provide an in-depth review of Amazon DynamoDB and Amazon DocumentDB to understand each service and how they compare.
DynamoDB and DocumentDB: An Overview
Amazon DynamoDB is a serverless, fully managed NoSQL database that supports key-value and document data models. It offers single-digit millisecond latency and can scale up and down to serve more than 20 million requests per second. It also supports data ranging from 1 gigabyte to 1 petabyte, allowing developers to build demanding, responsive, scalable, and reliable applications.
Amazon DocumentDB is a fully managed NoSQL database built for managing JSON data models. It offers a fully scalable, low latency service to manage mission-critical MongoDB workloads. It automatically replicates six copies of your data across 3 availability zones to offer a 99.99% availability. Additionally, it can serve millions of requests per second, enabling developers to build highly available and low latency applications.
DynamoDB and DocumentDB: Shared Attributes
Apart from both databases being NoSQL, these services can scale up on demand to query large datasets within a few milliseconds. Additionally, AWS fully manages these two services. Therefore, developers do not need to provision and manage SSDs, and storage clusters.
However, these services are different in terms of the data storage model. For example, DocumentDB does not support a key-value data model, while DynamoDB supports it. Hence, DynamoDB can scale horizontally, making DynamoDB a more scalable service than DocumentDB.
Furthermore, DynamoDB can store petabytes of data in a table with a 400KB per item constraint. But, DocumentDB has a maximum storage limit of 64 TiB (tebibyte) for the database.
DynamoDB vs DocumentDB: Performance & Latency
DynamoDB uses an array of SSDs spread across multiple partitions to store data in a table. Additionally, it uses a hash function to locate the partition that stores the required data. Hence, DynamoDB offers a single-digit millisecond latency to every request, and it scales up based on demand to service more than 20 million requests per second without performance loss.
Additionally, developers can integrate DynamoDB Accelerator (DAX) to improve read performance and achieve microsecond latency.
DocumentDB has a scalable in-memory optimized architecture that allows the database to evaluate queries faster for larger datasets. Furthermore, DocumentDB uses 15 read replicas to provide a higher read throughput to process millions of requests per second without throttling.
Finally, each replica shares the same underlying storage as the source instance. Therefore, it does not perform additional writes to the replica nodes when data gets updated. As a result, it allows DocumentDB to free up more processing power to serve more read requests and decrease its replica lag-time to single-digit milliseconds.
DynamoDB vs DocumentDB: Availability & Durability
DynamoDB is a highly durable database as it spreads the incoming traffic across multiple services to ensure that each server performs optimally and can effectively manage the load without throttling. As a result, the servers do not unexpectedly go down due to high loads, thus ensuring high availability.
DynamoDB replicates the data across multiple availability zones (AZs), providing high availability. If one server goes down, the users can still get access to the data replicated at an availability zone.
DocumentDB allows developers to create 15 read replicas across multiple availability zones. In addition, it improves availability because whenever an instance fails, DocumentDB automates failover to a read replica. Ultimately, this helps users access data even when an instance fails.
DynamoDB vs DocumentDB: Security
DynamoDB supports encryption at rest using encryption keys stored at AWS Key Management Service. Developers are free to configure the encryption using three KMS key types.
- AWS Owned Key: The default, free encryption type offered by AWS and DynamoDB owns the encryption key.
- AWS Managed Key: You can store the key in your AWS account and let AWS KMS manage it.
- Customer Managed Key: Developers are given the ability to create and manage the KMS key.
Please note that encryption methods 2 and 3 are subjective to KMS charges.
Additionally, DynamoDB allows developers to declare granular access to DynamoDB resources using the IAM service.
DocumentDB runs inside a VPC. As a result, it provides developers the flexibility to define firewall settings that help control network access to the cluster (storage volume + EC2 instance).
DocumentDB supports encryption at rest with the 256-bit Advanced Encryption Standard (AES-256) using symmetric encryption keys stored at AWS KMS. However, this is not enabled by default.
In addition, only clusters created using the AWS Console have encryption at rest enabled by default.
However, please note that:
- You can only configure encryption at rest only when you create a cluster.
- You cannot disable encryption at rest once you've enabled it.
DocumentDB, by default, supports encryption in transit using TLS to ensure that only secure connections using TLS can connect to the cluster. As a result, it ensures that the data remains encrypted when transferred from the cluster storage to the client, thus avoiding man-in-the-middle attacks.
DynamoDB vs DocumentDB: Scalability
As discussed earlier, DynamoDB is highly scalable and can serve over 20 million requests per second without performance loss. It uses two capacity modes to allow this.
- Provisioned: The required minimum and maximum WCU and RCU units are specified when the table gets created. You may use this if your application has a never-changing traffic flow.
- On-Demand: DynamoDB scales the capacity units up and down based on the application workload and traffic. If your application does not have a predictable traffic flow, you may use this.
DocumentDB is also a highly scalable database service. It allows developers to scale the cluster's storage and compute to help scale the database as data and traffic grow. Therefore, DocumentDB provides four types of scaling.
- Storage Scaling: This happens automatically by DocumentDB as the data grows in size. DocumentDB will scale the storage up to 64 TiB.
- Instance Scaling: This allows the instance performance to be improved. Typically, this is done manually by updating the cluster's instance class.
- Read Scaling: This allows the developers to increase the number of replicas in the cluster to improve read performance.
- Write Scaling: This allows developers to update the size of the cluster's primary instance to help improve write performance across multiple AZs.
DynamoDB vs DocumentDB: Backups
DynamoDB provides two backup mechanisms.
- Point-in-time recovery: This helps DynamoDB maintain continuous backups of table data for the last 35 days allowing developers to seamlessly restore data within 35 days in case of accidental deletes/updates. Additionally, it will restore the data present in the GSIs as well. However, this feature is disabled by default.
- On-demand backups: This allows developers to create full table backups with no performance overhead.
DocumentDB offers two types of backups.
- S3 Backups: DocumentDB automatically creates backups for data during the past 35 days on Amazon S3.
- AWS Backup: DocumentDB now supports AWS Backup. Therefore, developers can create snapshots of their table data on AWS Backup and perform restores directly from AWS Backup.
DynamoDB vs DocumentDB: Pricing
DynamoDB charges you for the resources that you consume. For example, you get billed for reading, writing, and storing data in your table. Additionally, you may get billed for any additional DynamoDB services (streams) that you use.
However, DynamoDB creates the pricing model based on the capacity model.
- On-Demand Pricing - In this model, AWS calculates your bill based on the WCU and RCU that you consume for the month. In addition, you may also get billed for the used backup storage and other DynamoDB services that you may consume.
- Provisioned Pricing - You pay for the provisioned write and read capacity units per table in this model. Therefore, you must pay for the provisioned units even if you do not use them.
On the other hand, DocumentDB has a strict model of only paying for what you use, requiring no upfront payments.
This pricing model comprises four dimensions.
- On-demand instances: This denotes the amount of compute instances per cluster. (Note that you are billed per second with a 10-minute minimum)
- Database I/O: The cost for reading and writing data to the cluster's storage volume.
- Database storage: The amount of data stored in the cluster's storage volume (per GB/month).
- Database backup storage: This denotes the amount of backup storage used.
Please note that the pricing for these four dimensions will differ by region.
Additionally, suppose your organization has not created a DocumentDB cluster. In that case, AWS offers a one-month trial with 750 hours of a "t.3" compute instance, 30 million IOs, 5 GB of storage, and 5 GB of backup storage.
DynamoDB vs DocumentDB: Use Cases
DynamoDB is a fast NoSQL database that offers single-digit millisecond latency to any request at any scale, making it far superior to most NoSQL databases.
Therefore, DynamoDB is a good option when building applications that process millions of concurrent requests per second and require quick response times for each request with no performance overheads.
For example, you can use DynamoDB in the following situations:
- Building scalable, fast applications.
- Building a near-real-time application such as a sensory application.
On the other hand, DocumentDB is a NoSQL database used to manage JSON data models. Because of this, DocumentDB provides its end-users with flexible schema management.
Therefore, DocumentDB is a good option when building applications with an ever-changing schema.
For example, you can use DocumentDB in the following situations:
- Building a user profile.
- Managing big real-time data.
- Content management.
This article explored an in-depth walkthrough of Amazon's DynamoDB and DocumentDB to understand each service and how they compare. There is no "best" database that you can use. Instead, you can determine the database service to use in your application based on your use case.
I hope that you found this article helpful! Thank you for reading!