Comparing DynamoDB and MongoDB

What is DynamoDB?

DynamoDB is a proprietary NoSQL database service built by Amazon and offered as part of the AWS portfolio. DynamoDB is known for providing performance consistency at scale.

What is MongoDB?

MongoDB is an open, document (non-tabular) database built by MongoDB, Inc.

MongoDB stores data in flexible, JSON-like records called documents. This model maps to objects in application code, making data easy to work with for developers. Related information is typically stored together for fast query access through the MongoDB query language.

Terminology and Concepts

Many concepts in DynamoDB have close analogs in MongoDB. The table below outlines some of the common concepts across DynamoDB and MongoDB.

Deployment Environments

MongoDB can be run anywhere—from a developer’s laptop to an on-premises data center to any of the public cloud platforms. As mentioned above, MongoDB is also available as a fully managed cloud database with MongoDB Atlas. This model is most similar to how DynamoDB is delivered.

In contrast, DynamoDB is a proprietary database only available on AWS. While a downloadable version of the database is available for prototyping on a local machine, the database can only be run in production in AWS. Organizations looking into DynamoDB should consider the implications of building on a data layer locked into a single cloud vendor.

Data Model

MongoDB stores data in a JSON-like format called BSON, which allows the database to support a wide spectrum of data types including dates, timestamps, 64-bit integers, and Decimal128. MongoDB documents can be up to 16 MB in size; with GridFS, even larger assets can be natively stored within the database.

MongoDB provides built-in schema validation. Users can enforce checks on document structure, data types, data ranges, and the presence of mandatory fields. As a result, DBAs can apply data governance standards, while developers maintain the benefits of a flexible document model.

DynamoDB is a key-value store with added support for JSON to provide document-like data structures that better match with objects in application code. An item or record cannot exceed 400KB. Compared to MongoDB, DynamoDB has limited support for different data types. For example, it supports only one numeric type and does not support dates. As a result, developers must preserve data types on the client, which adds application complexity and reduces data re-use across different applications. DynamoDB does not have native data validation capabilities, forcing developers to implement it manually.

Queries

MongoDB's API enables developers to build applications that can query and analyze their data in multiple ways—by single keys, ranges, faceted search, graph traversals, JOINs and geospatial queries through to complex aggregations, returning responses in milliseconds. Complex queries are executed natively in the database without requiring additional analytics frameworks or tools. This helps users avoid the latency increase provoked by syncing data between operational and analytical engines.

DynamoDB supports key-value queries only. For queries requiring aggregations, graph traversals, or search, data must be replicated into additional AWS technologies, such as OpenSearch or Redshift, increasing latency, cost, and developer work. AWS offers “Zero-ETL” integrations to connect additional AWS services with DynamoDB. However, these integrations are available in a limited number of regions, and the cost and complexity sprawl derived from managing disparate services still remains.

Indexes

MongoDB ensures fast access to data by any field with full support for secondary indexes. Indexes can be applied to any field in a document, down to individual values in arrays. Supported indexing strategies such as compound, unique, array, partial, TTL, geospatial, sparse, hash, wildcard, and text ensure optimal performance for multiple query patterns, data types, and application requirements. Indexes are strongly consistent with the underlying data.

DynamoDB indexes are views of their underlying tables (base tables). They are queried against directly and, therefore, they require to be sized and provisioned accordingly, which may result in unforeseen issues at runtime. DynamoDB indexes can only be defined as hash or hash-range; more advanced indexing strategies are not supported.

DynamoDB supports two types of indexes: Global secondary indexes (GSIs) and local secondary indexes (LSIs). Users can define up to five LSIs and 20 GSIs per table.

LSIs can be queried to return strongly consistent data, but must be defined when the table is created. They cannot be added to existing tables nor removed without dropping the table. For these reasons, GSIs are usually the go-to solution for querying non-primary fields.

GSIs, which are eventually consistent with the base table, do not support ad-hoc queries and usage requires knowledge of data access patterns in advance. GSIs can also not index any element below the top level record structure – so you cannot index nested fields, sub-documents or arrays.

Consistency

MongoDB is strongly consistent by default, as all reads and writes go to the primary in a MongoDB replica set, scaled across multiple partitions (shards). If desired, consistency requirements for read operations can be tuned. Through secondary consistency controls, read queries can be routed only to secondary replicas that fall within acceptable consistency limits with the primary server.

DynamoDB is eventually consistent by default. Users can configure read operations to return only strongly consistent data, but this doubles the cost of the read (see pricing and commercial considerations) and adds latency. There is also no way to guarantee read consistency when querying against DynamoDB’s global secondary indexes (GSIs); any operation performed against a GSI will be eventually consistent, returning potentially stale or deleted data and, therefore, increasing application complexity.

Transactions

MongoDB supports multi-document ACID transactions, making it the only database to combine the ACID guarantees of traditional relational databases; the speed, flexibility, and power of the document model; and the intelligent distributed systems design to scale out and place data where you need it.

Learn more on our MongoDB transactions page.

DynamoDB only supports single-region, multi-record ACID transactions for base tables. Unlike MongoDB transactions, each DynamoDB transaction is limited to just 100 write operations, and interactive transactions (read-before-write) are not supported. As a result, complex business logic may require multiple, independent transactions, which would add more code and overhead to the application, while also resulting in the possibility of more conflicts and transaction failures.

Operational Maturity

MongoDB Atlas allows users to deploy, manage, and scale their MongoDB clusters using built-in operational and security best practices, such as end-to-end encryption, network isolation, role-based access control (RBAC), VPC peering, and more. Atlas deployments are guaranteed to be available and durable with distributed and auto-healing replica set members and continuous backups with point-in-time recovery to protect against data corruption. MongoDB Atlas is fully elastic, with zero downtime configuration changes, and auto-scaling both storage and compute capacity. Atlas also grants organizations deep insights into how their databases are performing with a comprehensive monitoring dashboard, a real-time performance panel, and customizable alerting.

For organizations that would prefer to run MongoDB on their own infrastructure, MongoDB, Inc. offers advanced operational tooling to handle the automation of the entire database lifecycle, comprehensive monitoring (tracking 100+ metrics that could impact performance), and continuous backup. Product packages like MongoDB Enterprise Advanced bundle operational tooling and visualization and performance optimization platforms with end-to-end security controls for applications managing sensitive data.

MongoDB’s deployment flexibility allows single clusters to span racks, data centers, and continents. With replica sets supporting up to 50 members and geography-aware sharding across regions, administrators can provision clusters that support global deployments, with write local-read global access patterns and data locality. Using Atlas Global Clusters, developers can deploy fully managed “write anywhere” active-active clusters, allowing data to be localized to any region. With each region acting as primary for its own data, customers can meet the data sovereignty demands of new privacy regulations. Finally, multi-cloud clusters enable users to provision clusters that span across AWS, Azure, and Google Cloud, giving maximum resilience and flexibility in terms of data distribution.

Offered only as a managed service on AWS, DynamoDB abstracts away its underlying partitioning and replication schemes. While provisioning is simple, other key operational tasks are lacking when compared to MongoDB:

• 35 database metrics are reported by AWS Cloudwatch, which limits visibility into real-time database behavior
• DynamoDB has limited tooling to allow developers or DBAs to optimize performance by visualizing schema or graphically profiling query performance
• DynamoDB supports cross-region replication with multi-primary global tables, however these add further application complexity and cost, risks of data loss due to write conflicts between regions, no data sovereignty controls and no automatic client failover

Pricing and Commercial Considerations

Pricing for MongoDB Atlas is relatively straightforward by selecting just:

• The instance size with enough RAM to accommodate the portion of your data (including indexes) that clients access most often.
• The number of replicas and shards that will make up the cluster.
• Whether to include fully managed backups.
• The region(s) the cluster needs to run in.

Users can adjust any of these parameters on demand. The only additional charge would be for data transfer costs.

In contrast, DynamoDB's pricing model is based on throughput. Users pay for a specific capacity on a given table, and AWS automatically throttles any reads or writes that exceed that capacity.

This sounds simple in theory, but correctly provisioning throughput and estimating pricing is far more nuanced. There are more than 15 factors that could impact the cost of running DynamoDB. To highlight a few, the number of indexes and multi-region replication multiply throughput cost, and single-region strongly consistent reads are twice as expensive as eventually consistent ones.

When to use DynamoDB vs. MongoDB

DynamoDB may work for organizations that are:

• Looking for a database to support relatively simple key-value workloads.
• Heavily invested in AWS with no plans to change their deployment environment in the future.

For organizations that need their database to support a wider range of use cases with more deployment flexibility and no platform lock-in, MongoDB would likely be a better fit.

For example, biotechnology giant Thermo Fisher migrated from DynamoDB to MongoDB for its Instrument Connect IoT app, saying that while both databases were easy to deploy, MongoDB Atlas allowed for richer queries and much simpler schema evolution.