dynobase-icon
Dynobase

DynamoDB vs DocumentDB - The Ultimate Comparison

Lakindu Hewawasam

Written by Lakindu Hewawasam

Published on May 23rd, 2022

    Still using AWS console to work with DynamoDB? 🙈

    Time to 10x your DynamoDB productivity with Dynobase [learn more]

    Amazon DynamoDB and Amazon DocumentDB are two of Amazon's most popular cloud-based NoSQL database solutions. However, both services have 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

    DynamoDB

    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. DynamoDB is particularly well-suited for applications requiring consistent, low-latency data access at any scale.

    DocumentDB

    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 three 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. DocumentDB is designed to be compatible with MongoDB, making it easier for developers to migrate their existing MongoDB applications to AWS.

    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, so developers do not need to provision and manage SSDs and storage clusters.

    However, these services differ 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 it a more scalable service than DocumentDB.

    Furthermore, DynamoDB can store petabytes of data in a table with a 400KB per item constraint. In contrast, DocumentDB has a maximum storage limit of 64 TiB (tebibyte) for the database.

    DynamoDB vs DocumentDB: Performance & Latency

    DynamoDB

    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 single-digit millisecond latency to every request and 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. DAX is a fully managed, highly available, in-memory cache for DynamoDB that delivers up to a 10x read performance improvement.

    DocumentDB

    DocumentDB has a scalable in-memory optimized architecture that allows the database to evaluate queries faster for larger datasets. Furthermore, DocumentDB uses up to 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

    DynamoDB is a highly durable database as it spreads the incoming traffic across multiple servers 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 access the data replicated at another availability zone.

    DocumentDB

    DocumentDB allows developers to create up to 15 read replicas across multiple availability zones. This 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

    DynamoDB supports encryption at rest using encryption keys stored at AWS Key Management Service (KMS). Developers are free to configure the encryption using three KMS key types:

    • AWS Owned Key: The default, free encryption type offered by AWS, where 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 subject to KMS charges.

    Additionally, DynamoDB allows developers to declare granular access to DynamoDB resources using the IAM service. This enables fine-grained access control, ensuring that only authorized users and applications can access specific data.

    DocumentDB

    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 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

    DynamoDB

    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 predictable 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

    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

    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

    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

    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.

    DocumentDB

    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

    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.
    • E-commerce platforms that require high throughput and low latency.
    • Gaming applications that need to handle large volumes of player data in real-time.
    • IoT applications that collect and process data from numerous devices.

    DocumentDB

    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.
    • Applications that require complex querying capabilities.
    • Migrating existing MongoDB workloads to a managed service.

    Conclusion

    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!

    Tired of AWS Console? Try Dynobase.

    First 7 days are. No credit card needed.

    Product Features

    Download
    /
    Changelog
    /
    Pricing
    /
    Member Portal
    /
    Privacy
    /
    EULA
    /
    Twitter
    /
    Affiliates & Influencers
    © 2024 Dynobase