Close-to-the-metal architecture handles millions of OPS with predictable single-digit millisecond latencies.
Learn MoreAdvantages of Using DynamoDB
What is DynamoDB? Offered as part of the Amazon Web Services (AWS) cloud service platform, Amazon DynamoDB is a fully managed NoSQL database service. It’s a key-value database that also supports document data model using JSON. It features encryption at rest (“built-in security”); continuous backups, multi-region replication, in-memory caching (DAX) at added cost.
There are many advantages to using Amazon DynamoDB database just as there are many DynamoDB use cases:
DynamoDB scalability and performance. DynamoDB tracks how close usage is to upper bounds, allowing the user to auto-scale and the system to adjust based on data traffic. This reduces costs and improves performance.
Access to control rules. DynamoDB permits fine-grained access control over the data by the table owner. This helps smooth workflows and avoids creating bottlenecks.
Persistence of event stream data. Time-ordered streams within the AWS database DynamoDB enable developers to receive and update item-level data both before and after DynamoDB updates.
Time-to-Live (TTL). The Time-to-Live (TTL) process allows users to set timestamps for automatic deletion of expired table data. This reduces manual deletion costs and DynamoDB storage size.
AWS DynamoDB modeling. Storage of inconsistent schema items is possible in the Amazon DynamoDB data model. Since DynamoDB uses a NoSQL data model, it more efficiently handles less structured data than do relational data models. This improves query performance for item storage and makes it easier to address query volumes in inconsistent DynamoDB schemas.
Automatic data management. DynamoDB creates a constant, ongoing cloud backup for safety.
Challenges of DynamoDB
Since DynamoDB provides fast data transactions for applications, its focus is on speed. However, the same factors that speed DynamoDB transactions can also hinder data analysis.
Cost. DynamoDB can be very expensive. Teams pay for read and write transactions and are charged by the hour – plus storage and optional services. Benchmarks find that DynamoDB is often up to 7x more expensive than compatible database-as-a-service options with similar or better performance. Companies spend a great deal of time and engineering effort in their attempts to reduce their DynamoDB costs. [Compare costs vs Astra, Keyspaces, and ScyllaDB Cloud with this cost calculator].
Deployment lockin. Comparable database-as-a-service offerings include BYOA (bring your own account) or let you run the same core database unmanaged using other cloud infrastructure (AWS, GCP, MS Azure…), in a hybrid or on-premises environment. DynamoDB does not.
Autoscaling. DynamoDB autoscaling can only add capacity so fast, and its knowledge about the traffic patterns is very limited. This means that autoscaling cannot deal with unexpected large changes in capacity. It’s also commonly quite costly. Teams often find that autoscaling can be too slow for bursty traffic, forcing them to leave a high minimum throughput (which is expensive) or managed scaling themselves (which is work teams typically try to avoid by paying for a fully-managed service). [Read about iFood’s struggle with autoscaling].
Online analytical processing (OLAP). Systems that undertake online analytical processing and data warehousing typically demand massive amounts of data aggregation, and a normalized or relational view of data via joined dimensional tables. Because DynamoDB is a non-relational database that works better with NoSQL formatted data tables, general data structures for analytics aren’t as well supported, and DynamoDB analytics are more challenging to run.
Querying DynamoDB. Querying DynamoDB is also more difficult as DynamoDB does not interface with SQL. This is important because most developers are more familiar with SQL than DynamoDB queries.
Indexing costs. While indexing can help reduce the cost of analytics processing, indexing is more expensive with DynamoDB. This is because DynamoDB’s global secondary indexes must provision additional read and write capacity to function.
DynamoDB Performance
Amazon DynamoDB is a key-value database used by over 100,000 AWS customers such as Netflix, Nike, and Lyft. DynamoDB database design is intended for internet-scale entertainment, gaming, IoT, media, mobile, retail, and web applications that demand low-latency access to data.
A range of automated and native AWS capabilities and management features support DynamoDB performance and enable easier integration with other AWS services. Key DynamoDB metrics and performance capabilities include:
- Tables replicate data across AWS regions automatically so globally distributed applications can access data locally for rapid read and write performance
- Scales tables up and down automatically to maintain performance and adjust for capacity
- DynamoDB performance tests reveal monthly uptime of 99.999% SLA per AWS region
- Fully managed in-memory caching dramatically reduces read time
- Backups affect neither application performance or availability—even for hundreds of terabytes
- Application performance monitoring scales up and down automatically with application traffic
ScyllaDB vs DynamoDB
DynamoDB, ScyllaDB, and Cassandra all grew from the same project: Bigtable. Cassandra and DynamoDB have evolved separately, but ScyllaDB unites them as an offering which can interoperate with them both.
ScyllaDB, the fastest NoSQL Database, is API compatible with both Apache Cassandra and Amazon DynamoDB. ScyllaDB lets DynamoDB users switch to new open source options without changing a single line of application code, and run on their preferred cloud platforms, on-premises, or on ScyllaDB’s fully managed database as a service, ScyllaDB Cloud—the industry’s most performant NoSQL database as a service.
ScyllaDB supports the same client SDKs, data modeling and queries as DynamoDB. However, teams can deploy ScyllaDB wherever they want: on-premises, or on any public cloud. ScyllaDB provides lower latencies and solves DynamoDB’s high operational costs. There’s no platform lock-in and multiple deployment options, including open source Kubernetes and Docker.
Implemented in C++ rather than Java, ScyllaDB nonetheless shares many characteristics of a DynamoDB or other NoSQL database. For example, AWS DynamoDB high availability derives from column families with tunable consistency—also present with ScyllaDB. It is commonly selected over DynamoDB when teams are looking for a low-cost, extremely fast and scalable NoSQL database.
Cassandra vs DynamoDB
Apache Cassandra and DynamoDB are both NoSQL databases that are often selected for geographically distributed applications that are growing fast and require low latency. DynamoDB is often selected for its simplified administration and maintenance vs Cassandra. Cassandra is often selected vs DynamoDB due to lower costs, its lower costs at scale than DynamoDB, as well as the additional control and flexibility associated with it being an open source database.
Replication
NoSQL data stores such as DynamoDB and Cassandra use multiple data copies to ensure durability and high availability. With Cassandra, the number of replicas per cluster is the replication factor and the user can control it.
In contrast, with DynamoDB, data is located in a single region by default and replicates to three availability zones there. For multi-region replication, Amazon streams must be enabled. However, DynamoDB limits the number of tables in an AWS region to 256, while in Cassandra the practical limit is about 500 tables.
The maximum item size in DynamoDB is 400KB. In Cassandra, the practical limit is a few megabytes although the hard limit is 2GB.
Keys and clustering
Because it is a schemaless database, only the primary key DynamoDB attributes need to be defined when the table is created. However, consider the costs of read and write throughput at the time of table and application design.
The DynamoDB primary key and sort key can each have only one attribute. Cassandra allows multiple clustering columns and composite partition keys. Cassandra supports different data types from DynamoDB types.
To set up clusters, both Cassandra and DynamoDB demand capacity planning, but their approaches are different. Creating capacity for a performant Cassandra cluster requires a good data model, a properly sized cluster, and the right hardware. With DynamoDB, the type of read/write capacity modes selected determines the nature of capacity planning.
The hashed value of both Cassandra and AWS DynamoDB partition keys form the basis for data grouping and distribution. These are called grouping partitions in both systems, but they are defined in very different ways based on size, partition key values, and limits.
Accessing data
Cassandra uses Cassandra Query Language (CQL) to access data, an SQL-like language. In DynamoDB JSON is the syntax.
TTL
The Time To Live (TTL) feature removes items from a table automatically after a specific period of time. In Cassandra TTL is the number of seconds from row creation or update, while TTL is a timestamp value that represents a specific expiration time and date in DynamoDB. Cassandra applies TTL to the column, while DynamoDB applies it at item level.
Consistency
Since both DynamoDB and Cassandra are distributed systems, they always face a tradeoff between consistency and availability, which leads to two possible consistency states:
- Eventual consistency. Eventually consistent systems maintain speed, but reads may return stale data until all copies are consistent; updates reach all replicas, but eventually.
- Strong consistency. Strongly consistent systems return up-to-date data for all prior successful writes but decrease availability and reduce response time.
The DynamoDB default is eventual consistency although it supports eventually consistent and strongly consistent reads on a per query basis.
Strongly consistent reads in DynamoDB may not be available in case of outage or delay, and the operation can have higher latency. Global secondary indexes (GSIs) do not support strongly consistent reads. Strongly consistent reads also cost more than eventually consistent reads as they use more throughput capacity.
Cassandra offers strong, tunable consistency for both reads and writes, but again, increasing latency is a tradeoff.
Encryption
Both Cassandra and DynamoDB use encryption for inter-node and client communication. DynamoDB encryption at rest also exists. The principle of “last write wins” applies only to strongly consistent reads and global tables for the sake of DynamoDB consistency.
Scans
Scans are costly for both Cassandra and DynamoDB. Cassandra must scan all nodes in the cluster, making the process slow. DynamoDB scans are faster, but also more expensive, because DynamoDB resource use is based on the data amounts returned. DynamoDB will generate errors if the scan exceeds your provisioned DynamoDB read capacity.
Advantages
DynamoDB advantages include an absence of database management burden; an easy start; plenty of availability, flexibility, and auto scaling; built-in monitoring metrics; and at-rest data encryption. DynamoDB is commonly selected by organizations making extensive use of AWS products.
Cassandra’s main advantages include constant availability; relatively fast read and write speeds; reliable cross data center replication; linear scalability; Cassandra Query Language which is familiar and SQL-like rather than DynamoDB’s complex API; and generally high performance. Cassandra is a better choice for applications that demand strong read consistency, teams that need open source tools such as Apache Spark, Apache Kafka, or ElasticSearch, or organizations that run their own data centers or use cloud providers other than AWS.
MySQL vs DynamoDB
MySQL is an open source SQL server widely adopted by web and application developers. In 2008 it was acquired by Oracle; now available as both open source and proprietary enterprise editions.
MySQL and DynamoDB are distinctly different database technologies. In contrast to the DynamoDB NoSQL database, MySQL is a relational (SQL) database. [learn about the differences between SQL and NoSQL]
Relational databases like MySQL store data in tables connected with relations. Structured Query Language (SQL) is used to query the database. SQL databases are comprised of records organized into tables. In a single table, data is organized into rows, labeled with a primary key, and with many columns (columnar databases) to hold values for different kinds of data – typically large data sets. These tables are related to each other through the use of foreign keys, which join together the different tables in the database.
In contrast, the DynamoDB database type (key-value NoSQL) associates named keys to values of any type, including complex types. A key value store is useful for storing simple collections of mixed types where the data being stored would not logically contain the same columns.
DynamoDB vs MongoDB
What are the differences between MongoDB and DynamoDB?
Environment
One important difference between DynamoDB vs MongoDB is deployment environment and strategy. MongoDB is platform-agnostic and one of the leading DynamoDB alternatives.
DynamoDB is limited to Amazon Web Services (AWS).
MongoDB can be configured to run virtually anywhere from a container, a local machine, or through any cloud provider. In contrast, you can only configure and use DynamoDB and DynamoDB tools through AWS. DynamoDB is a native AWS application, with much tighter integration with other AWS tools and services.
DynamoDB is fully managed, which means DynamoDB provisioning only takes a few clicks, even for multiple regions, dramatically reducing the need for dedicated management of infrastructure.
MongoDB requires users to configure and manage infrastructure for MongoDB deployments, although MongoDB Atlas offers a fully managed multi-cloud, multi-region NoSQL solution and cloud database service that can be deployed across Google Cloud, Microsoft Azure, and AWS.
Data model
The MongoDB data model and schema are different in that MongoDB stores data in documents using the BSON format with support for more data types and document sizes. In contrast, DynamoDB data types and document sizes are more limited. It does, however, support document data models using JSON.
MongoDB is a schema-free database, yet its built-in schema validation allows users to enforce a schema as needed, including for document structure, data types, fields, and more. In contrast, DynamoDB is schema-free and lacks the ability to enforce schemas. With both MongoDB and DynamoDB ACID compliance is possible.
Flexibility
MongoDB is more flexible in querying data and indexes, allowing users to aggregate data natively in multiple ways: graph traversals, JOINs, ranges, single keys, and more.
DynamoDB is less flexible, natively supporting only key-value queries. However, by enabling other AWS services such as Elastic MapReduce, it allows users to carry out complex aggregations. There is a per retrieval DynamoDB query limit of 1MB of data. However, all of these services increase complexity, cost, and latency.
MongoDB supports creating indexes and different indexing types such as array, compound, hash, TTL, text, wildcard, etc. The indexes and underlying data are strongly consistent.
DynamoDB, in contrast, supports two types of secondary indexes: DynamoDB Global Secondary Index (GSI) or DynamoDB GSI encompasses all base table data across all partitions and can be scaled and stored apart from the underlying data table. DynamoDB Local Secondary Index (LSI) or DynamoDB LSI matches the value of the table partition key to the LSI partition key, limiting the scope to the base table.
Both LSI and GSI in DynamoDB support multi-document transactions, but DynamoDB lacks support for multiple operations within a single transaction. MongoDB supports reads and writes to the same fields and documents in a single transaction.
Security
DynamoDB best practices for security are based on AWS Identity and Access Management (IAM) and managed by AWS so it is secure by default. This model offers users fine-grained control over DynamoDB roles, users, and policies.
MongoDB Atlas offers enhanced security practices, such as encryption and network solutions for authorization and authentication. In other words, you can securely manage MongoDB, but the default configuration is still more difficult to secure.
Both DynamoDB and MongoDB Atlas support encryption of data at rest.
DynamoDB backup and recovery
DynamoDB is a serverless, maintenance-free, distributed system that scales, provisions, and heals itself automatically. DynamoDB continuous backup is part of on-demand, automated, point-in-time recovery.
MongoDB Atlas requires more configurations than DynamoDB, but also supports continuous and on-demand cloud backups and allows users to provision and manage MongoDB clusters across various multi-cloud environments.
Speed
MongoDB Atlas delivers significantly better query performance than what you would find with DynamoDB because it stores query data in RAM. MongoDB Atlas may be the best choice if speed is a concern and the data set fits in RAM.
Programming languages, skill level
MongoDB supports almost all of the major programming languages, making it more flexible. Supported languages include C, C++, C#, Clojure, Perl, PHP, PowerShell, and others. DynamoDB supports only Java, JavaScript, Node.js, Swift, PHP, .NET, and Python.
However, it takes more skill to implement and support MongoDB Atlas.
Ease of use
MongoDB is more flexible than DynamoDB. It is better-suited for applications without strict latency requirements, larger documents, geospatial data, and bursty workloads. There are more available data types, and users can run MongoDB anywhere.
While it delivers impressively consistent performance, design and data modeling in DynamoDB can be more difficult—particularly for people used to working with relational databases. It’s also essential to understand global and local secondary indexes as part of DynamoDB data modeling.
Vendor lock-in
A major downside to using DynamoDB is vendor lock-in, which can leave users without the ability to easily change the deployment environment. This makes it harder to focus on a multi-cloud strategy.
DynamoDB cost
DynamoDB pricing is lower for those who have heavily invested in the AWS ecosystem, in the form of seamless integration with services and tools. It’s less complex and simpler to manage a multi-tiered DynamoDB architecture that supports all organizational cloud services consolidated into one cloud provider.
However, capacity management can be a serious challenge for DynamoDB users. DynamoDB autoscaling provisioned capacity is best suited for large, relatively predictable tables. Smaller tables or more unpredictable traffic can cause higher costs. Most workloads hosted on MongoDB clusters do not scale as well with a single API call but are cheaper overall with respect to data storage than DynamoDB.
Refer to the official MongoDB and DynamoDB documentation and other DynamoDB resources as an excellent base to dive deeper into each database and answer MongoDB and DynamoDB FAQ. Find AWS documentation for DynamoDB here. DynamoDB docs are not always as detailed as third-party sources.
Masterclass: Data Modeling for NoSQL Databases
Looking for extensive training on about data modeling for NoSQL Databases? Our experts offer a 3-hour masterclass that assists practitioners wanting to migrate from SQL to NoSQL or advance their understanding of NoSQL data modeling. This free, self-paced class covers techniques and best practices on NoSQL data modeling that will help you steer clear of mistakes that could inconvenience any engineering team.
DocumentDB vs DynamoDB
The DynamoDB DocumentDB comparison starts with both being non-relational databases, but with different purposes. Amazon DynamoDB is a serverless key-value database that delivers scalable, rapid performance, while Amazon DocumentDB is a fully managed, JSON NoSQL document database service that supports MongoDB workloads.
Amazon DocumentDB is partly compatible with MongoDB. DocumentDB runs atop the Amazon Aurora backend platform and mimics the MongoDB API. It is meant to serve as an alternative to and compete with MongoDB.
DynamoDB vs Redis
Redis (Remote Dictionary Server) is an open-source, fast, NoSQL database and among the leading alternatives to DynamoDB. Written in the ANSI C language, Redis works in most of the POSIX systems such as Linux, BSD, and OS X without external dependencies. Delivering sub-millisecond response times, Redis enables real-time applications in ad tech, financial services, gaming, healthcare, IoT, and social networking. It supports data structures such as bitmaps, hashes, hyperloglogs, lists, strings, sets, geospatial indexes with radius queries, and sorted sets with range queries.
The primary strength in this DynamoDB comparison is persistent storage, but Amazon DynamoDB Accelerator (DAX or DynamoDB DAX) is a highly available, fully managed, in-memory DynamoDB cache that keeps Redis and DynamoDB in about the same position and lets users retain the advantages of DynamoDB.
DAX DynamoDB accelerates DynamoDB table design without requiring management of data population, cache invalidation, or cluster management. It is easy to enable DAX in the AWS Management Console with a few clicks or by using the AWS DynamoDB SDK. DAX is also compatible with existing DynamoDB API calls.
DynamoDB vs Aurora
Amazon Aurora is a relational database solution that is compatible with MySQL and PostgreSQL. Among its basic design principles is writing in the foreground to minimize the problem seen in DynamoDB latency.
Aurora and DynamoDB encryption at rest are both supported using encryption keys. There are three ways to use Amazon DynamoDB keys to encrypt the table. The DynamoDB AWS-owned key is free and encrypted by default. KMS will also secure stored AWS-managed keys for a fee.
And KMS Customer Management Keys (CMKs) give total control over KMS keys to users.
DynamoDB and Amazon Aurora have similar permission schemes, but Aurora also offers MySQL and PostgreSQL-compatible connection interfaces.
Amazon S3 vs DynamoDB
Amazon Simple Storage Service (Amazon S3) is a scalable, high-speed, cloud storage service. It was developed for archiving and backing up data and applications on AWS. This object store holds large amounts of binary unstructured data grouped into buckets, each associated with a region.
DynamoDB was designed to store structured textual/JSON data, although it can also store binary objects. It stores items in tables, and DynamoDB global tables support multi-master replication.
Unlike DynamoDB which was designed for low latency and sustained usage patterns, Amazon S3 was designed not for predictable latency, but for throughput. It can handle many traffic requests, even for different items, without being overwhelmed.
With DynamoDB batch write you can write or delete massive quantities of data efficiently, or copy data into DynamoDB from another database. Amazon S3 supports automatic versioning, while DynamoDB version history doesn’t automatically support object versioning, although you can refer to the DynamoDB history table for the log of the past 24 hours.
DynamoDB vs Postgres
PostgreSQL, sometimes simply called Postgres, is an open-source, free relational database management system emphasizing SQL compliance and extensibility. A highly stable database management system, PostgreSQL is used as the primary data warehouse or data store for many analytics, geospatial, mobile, and web applications.
The main difference between PostgreSQL and DynamoDB is that DynamoDB is a NoSQL database engine that can support tables of any size, whereas PostgreSQL can store structured and unstructured data in a single product.
DynamoDB vs Redshift
Amazon DynamoDB is a fully-managed NoSQL database service that supports both key-value and document data models. Flexible and fast, DynamoDB is often selected for applications that need scalable, consistent low latency.
Amazon Redshift is a large-scale relational database management system (DBMS) and data warehouse service that is part of the Amazon Web Services cloud-computing platform. Amazon Redshift is intended for use with business intelligence tools.
While DynamoDB does not support SQL query language, Redshift does (although it does not fully support an SQL-standard).
DynamoDB has no foreign keys because it does not account for referential integrity. Redshift does accept foreign keys, accounting for referential integrity.
While DynamoDB does not support server-side scripting, Redshift supports user-defined functions for server-side scripting in Python. Finally, Redshift supports restricted secondary indexes, while DynamoDB simply supports secondary indexes.
DynamoDB vs MS SQL
Amazon DynamoDB is a cloud-based, scalable database that stores data on the Amazon cloud, while MS SQL is a secure, highly scalable relational database management system and platform for data storage that is not cloud-based.
MS SQL is immediately consistent, while DynamoDB has eventual consistency. MS SQL supports operating systems such as Linux and Windows, while Amazon DynamoDB supports hosted OS.
MS SQL supports SQL and is implemented in C++. DynamoDB does not support SQL, nor does it have C++ as its implementation language. Finally, MS SQL has server-side scripts, but DynamoDB does not.
