Redis vs. DynamoDB

Redis and DynamoDB are hugely popular datastores, and often some of the first systems web developers learn to work with. While they serve different purposes and rarely go head-to-head in consideration, picking one or the other can have long-term implications for the direction of future growth and what technologies can be added later.

Redis and DynamoDB: Supporting real-time application development

Real-time workloads are common in systems designed for online gaming, AdTech, fraud detection, and Internet of Things (IoT). But they're also becoming more common in systems that historically have been oriented toward legacy batch processing approaches, like financial reconciliation, logistics, and enterprise resource planning (ERP) and HR software. Supporting the accelerating transition to real-time everything is a class of modern NoSQL (and sometimes NewSQL) databases, many of which were built to be real-time-first and cloud-native (note: Redis may not be cloud-native, but it still supports many cloud applications and services).

Among this new class, Redis and DynamoDB stand out as giants in their space. Though they serve two different purposes in application architectures, they're both dominant: the former for its ease of use and implementation, and the latter for its plug-and-play integration in the AWS ecosystem. Often, the two are used together to address different storage tier needs: Redis as cache, DynamoDB as long-term storage.

We compare Redis to DynamoDB and examine where they shine and where they falter to help developers understand which one best supports their use case and what additional considerations each one adds to future growth planning.

What is Redis?

Redis began as an in-house solution for developer Salvatore Sanfilippo's startup, initially developed as an open-source, in-memory distributed cache and message broker, storing simple key-value pairs directly in RAM. Since launching as a stand-alone product, Redis has added optional persistence, the ability to store some additional data types, an enterprise version with cloud support, and transitioned from open-source to source-available.

What is Redis good at?

• Using memory for primary storage helps Redis achieve hyper-low latencies across most workloads.

• Redis was designed as a simple, minimalist solution, making core Redis easy and fast to get started with. 

• A large and active open source community means that finding support is never more than a forum post away, and extensive third-party tooling and plugins exist to handle almost any use case.

How is Redis deployed?

• The most common option is a source-available, self-hosted community option (available as open-source for older versions).

• Redis Enterprise provides options for self-managed cloud or local deployment with some additional functionality and support.

• A managed cloud hosting solution, Redis Cloud, allows for fully hands-off deployment.

What are common use cases for Redis?

• The biggest being caching

• Often used for server-side session state maintenance

• Message broker and decoupler in pub/sub messaging models

• More recently, Redis has been gaining increased adoption in streaming and AI, especially for search and recommendation engines.

What is DynamoDB?

DynamoDB, or DDB, was Amazon's answer to the rise of modern, automated NoSQL databases. Originally developed for internal use, DynamoDB improved on the original Dynamo system by adding native scaling automation for tasks like provisioning and re-partitioning database instances. Currently, DynamoDB is a fully managed, distributed, cloud-native NoSQL database tightly integrated into the AWS ecosystem and capable of storing key-value pairs and documents.

What is DynamoDB good at?

• DynamoDB is highly elastic and highly available, thanks to Amazon's massive AWS infrastructure.

• Additionally, DynamoDB is tightly integrated with all other AWS services, making it simple to initialize and start using from within the AWS ecosystem.

How is DynamoDB deployed?

• DynamoDB only offers a managed hosting option from within AWS using a serverless model.

• A local version is available for testing and development, but it is highly limited and unavailable for production deployment.

What are common use cases for DynamoDB?

• Application back-ends

• Retail catalogs and e-commerce back-end systems

• General-purpose key-value or document storage

• Primarily only used when the rest of the application or service is already built on AWS infrastructure

Comparing Redis and DynamoDB side-by-side: A technical look

In the following section, we will evaluate the technology and approaches used by Redis and DynamoDB for storing and managing user data.

Data and querying

How do Redis and DynamoDB store and access application data?

Data models

• Redis: Natively supports key-value pairs and offers support for JSON in the enterprise version with the addition of a module. Supported data types include strings, lists, sets, and ordered sets, including vector sets, hashes, streams, geospatial indexes, bitmaps, bitfields, and probabilistic data types like Bloom filters

• DynamoDB: Key-value pairs made up of scalar values (number, string, boolean, binary, or null), documents of varying complexity in list or map types, or sets of scalar values

Secondary indexing

• Redis: Secondary indexing isn't natively present, but can be implemented manually through custom scripting or available modules like RediSearch and third-party plugins

• DynamoDB: Full native implementation using global secondary indexes or local secondary indexes

Querying

• Redis: Primarily simple key-value access, but with an included abstraction layer that allows for options like text and vector search using the Redis Query Engine module

• DynamoDB: Native rich, flexible queries with extended API

Consistency models

• Redis: Eventual consistency in the community edition, with additional options to tune for stronger consistency in the Enterprise version

• DynamoDB: Strong eventual consistency for transactions and reads

Performance and latency

How do Redis and DynamoDB perform in real-world applications? Performance can be an abstract term since it might mean two very different things depending on the use case. Often, performance is a sliding scale between raw access speed and consistency, durability, and persistence. With Redis and DynamoDB, the two systems occupy almost diametrically opposed ends of that scale: Redis prioritizes speed while DynamoDB prioritizes durability and persistence. 

• Redis: Redis primarily uses memory for storage, leading to high performance and low latencies in most applications. However, there are some caveats to this. Redis uses a single-threaded approach; significant latency can be introduced during heavy persistence and replication workloads. There is also Redis Flex, a version using a hybrid RAM/SSD option that increases latencies somewhat while decreasing costs. (Typical latencies in microseconds.)

• DynamoDB: Uses SSDs for storage, so latencies are still reasonably low and performance reasonably high, but not as fast as RAM or hybrid storage approaches. Higher latencies are offset by stronger persistence and consistency, with less variability in access speeds. (Typical latencies in milliseconds.)

Scaling and availability

How readily do Redis and DynamoDB scale, and what features are included to help make data more available and durable?

Scaling

• Redis: Redis allows for sharding using the Redis Cluster module. However, the community edition offers highly limited options and is missing several core functions, like automatic resharding or elastic scaling, which are present in the enterprise version.

• DynamoDB: Native autosharding, with functionally infinite horizontal scaling (at a cost) thanks to the tight integration with Amazon's AWS infrastructure.

Availability

• Redis: Redis Sentinel for the community edition provides monitoring and offers a limited single-instance primary-replica failover; however, active-active replication and failover are only supported in Enterprise and Managed Cloud versions.

• DynamoDB: Native, full-featured failover with multi-region support and a full suite of high-availability features, plus hosting on Amazon's AWS infrastructure, makes DynamoDB five-nines available; if Amazon is still up, DynamoDB is probably still up.

Cross-region/-datacenter/-cloud distribution

• Redis: While offered in Redis Enterprise and Redis Cloud, the community edition does not support automated cross-region/-datacenter/-cloud distribution, making it an entirely manual process prone to complexity and potential performance degradation.

• DynamoDB: Native global distribution across regions and data centers with native global table functionality. However, due to its exclusivity to AWS, there's no support for direct cross-cloud distribution, requiring manual setup using third-party connectors.

Operations, cost, and support

How does the choice of Redis or DynamoDB affect an application's operational overhead?

Operational complexity

• Redis: The community is fully self-managed and relies on local deployments close to where data is being processed, making complexity high for larger implementations. However, Redis Cloud offers a fully managed deployment.

• DynamoDB: This is a fully managed serverless deployment with minimal operational overhead. However, a complex pricing structure and limited cost forecasting availability can result in high financial costs that are difficult to plan for.

Total cost of ownership

• Redis: Redis open-source costs are entirely infrastructure-dependent, while the managed Enterprise option adds significant, ongoing licensing costs. Due to the in-memory storage, operating costs can grow quickly, given the high cost of RAM.

• DynamoDB: Pricing is based on a combination of requests, storage, and additional features, which can quickly become complex and cumbersome. Automated scaling can create cost spikes that smaller applications and services are unprepared to handle.

Ecosystem, tooling, and support

• Redis: Redis' high popularity and active open-source developer community mean that many third-party CLI tools, modules, and plug-ins exist and are supported by a large knowledge base. Enterprise versions can benefit from these as well, along with having access to official support and more official modules. However, the move to source-available may decrease community support over time as open-source developers abandon the software.

• DynamoDB: As part of AWS's ecosystem, extensive documentation and support exist from the community and directly from Amazon. There's a lot of official tooling, though third-party tooling is more limited.

Suitability for use cases

How well do Redis and DynamoDB work for specific applications?

Caching

• Redis: Redis is the market leader for caching, especially in-memory caching. This was the primary design consideration for the system, making it an excellent fit for the purpose.

• DynamoDB: In standard form, it's too slow for most caching implementations. However, Amazon does offer a service called Dynamo Accelerator (DAX) that provides a significant improvement.

Serverless computing

• Redis: Doesn't provide a native answer for serverless integration in any of its versions, nor does it have any support for manually implementing it

• DynamoDB: Full integration into Amazon Lambda

Real-time analytics

• Redis: Both Redis open source and Redis Cloud have limited support for real-time analytics, and the primarily memory-based storage requires frequent data cycling or significant spend on RAM to make real-time analytics applications work.

• DynamoDB: While DynamoDB is better for this use case than Redis, it still introduces significant complexity and requires additional AWS services to do real-time analytics well, significantly adding to the cost.

Global data distribution and backup/archiving

• Redis: Not feasible with the tools available for open-source Redis, and only marginally better with Redis software or Cloud. Besides the lack of strong cross-region replication support, the high cost of RAM makes this infeasible for any Redis service other than Redis Flex.

• DynamoDB: Direct access to all of Amazon's infrastructure and integration with cold-storage solutions from AWS, along with native global tables, make DynamoDB excel at distributing data across a massive geographical area.

Large-scale applications

• Redis: RAM is too expensive to be used as primary storage for large-scale applications. If costs are kept manageable, applications with high data volumes will find that data is lost or overwritten quickly. Redis Flex is better, but it has limitations on how it can be deployed and customized for specific needs.

• DynamoDB: High volumes are easily supported, and the service can be scaled up and down quickly. However, the lack of significant economies of scale (very flat cost scaling) can make large deployments more expensive than competing products.

Low-latency applications

• Redis: Redis's high speeds make it a good fit for low-latency applications, so long as throughput and data volumes stay relatively low and the data doesn't need to persist for an extended amount of time. Otherwise, costs may be prohibitive.

• DynamoDB: Native DynamoDB is not fast enough to keep up with the needs of modern low-latency real-time applications. However, it can work when integrated with Dynamo Accelerator or Amazon ElastiCache. Both options add additional cost and complexity.

Choosing between Redis and DynamoDB

Redis and DynamoDB have different strengths and weaknesses, so it's rare that application developers will ever need to choose directly between the two. However, since opting for DynamoDB often locks applications into the AWS ecosystem, it's still worthwhile to consider the two side-by-side as part of a holistic architecture plan for real-time applications.

A developer's choice depends on the kind of data they're working with and what they need to do with it. If the primary goal is to move small amounts of data from A to B as quickly as possible and persistence is not a core concern, Redis is a solid option. Conversely, if the data is high-volume or needs to remain for any significant length of time, DynamoDB is a better fit.

However, from a broader systems architecture perspective, the choice is really Amazon or not Amazon. Both Redis and DynamoDB can be configured for similar performance, albeit with an edge toward speed for Redis and an edge toward scale for DynamoDB, especially when using add-on options like DAX or Redis Cloud/Enterprise. However, Redis Enterprise is cloud agnostic, supports a broader variety of infrastructures, and offers more integrations with third-party systems. Amazon DynamoDB allows for simpler maintenance and operational overhead, but at the cost of staying within Amazon's walled garden or implementing workarounds when moving data in and out.

In some instances, Redis and DynamoDB can be used together in different storage tiers; Redis as the cache layer and DynamoDB as a persistence layer. However, the use cases for this are rare since both services offer in-house options to achieve a similar effect without having to kludge anything together. These kinds of splits can provide a "best-of-both-worlds" solution, but add significant complexity and operational overhead in juggling data between the two layers and creating another potential failure point.

Ultimately, neither system does what the other does well. That leaves developers and architects who need super low latency and robust availability and durability to either pay significantly more for Redis and Amazon's in-house solutions, rely on Frankenstein measures, or look elsewhere.

Speed, volume, cost: A third option when you need it all

Application developers who need a system that can provide low latency, high availability, durability, and low total cost of ownership can consider Aerospike Database 8, part of the Aerospike real-time data management platform. Database 8 was designed from the ground up to provide low latencies, high throughput, high availability, and global replication.

Advantages of Aerospike Database 8 over Redis and DynamoDB include:

• Database 8 supports a larger variety of database models, including key-value, document, and graph, powered by a single database engine, and allows multi-model databases that combine these types within a single database. This capability is not found in either Redis or DynamoDB.

• Higher levels of customization allow Database 8 to be fine-tuned to specific needs, allowing architects to dynamically move the speed-persistence-availability-consistency slider to fit their application.

• By default, Hybrid Memory Architecture (HMA) combines memory for key storage and SSDs for value storage, offering functionality similar to Redis Flex but within the core Aerospike product.

• Global Cross Datacenter Replication (XDR) matches DynamoDB's availability and durability but adds native cross-cloud functionality that isn't locked to Amazon's AWS ecosystem.

• Database 8 is completely infrastructure-agnostic, giving users the option to host in any (or multiple) clouds, on-prem, or a combination of both. Self-managed or fully managed options are available to fit application and team needs.

• Aerospike Database 8's total cost of ownership is lower than that of Redis Enterprise/Cloud or DynamoDB, and it is less operationally complex.

If you've explored Redis and DynamoDB and found that neither is optimal for your use case, contact Aerospike to see if the Aerospike real-time data management platform can be the best of all worlds for your application.