Amazon MemoryDB FAQs

Amazon MemoryDB Multi-Region is a fully-managed, active-active, multi-Region database enabling you to build applications with up to 99.999% availability and microsecond read and single-digit millisecond write latency. It provides data redundancy across multiple AWS Regions, so you can improve availability and resiliency of your multi-Region applications, even if an application processing is interrupted in one Region and cannot connect to its MemoryDB endpoint. MemoryDB Multi-Region offers active-active replication so you can serve reads and writes locally from the Regions closest to your customers with microsecond read and single-digit millisecond write latency. It asynchronously replicates data between Regions, and data is typically propagated within a second. MemoryDB Multi-Region automatically resolves update conflicts and corrects for data divergence issues, so you can focus on your application.

You should use MemoryDB Multi-Region if you’re looking to build applications that need the highest levels of availability, increased resiliency, and improved business continuity. MemoryDB Multi-Region can also be used if you are looking to build and run multi-Region applications that require fast response time anywhere in the world.

When using MemoryDB Multi-Region, MemoryDB replicates data across regional clusters in a configuration called a multi-Region cluster. When data is written to any regional cluster within the multi-Region cluster, MemoryDB automatically and asynchronously replicates that data to all other regional clusters, typically within one second, without affecting your application's performance. MemoryDB Multi-Region automatically resolves update conflicts and corrects for data divergence issues. Conflict resolution is fully managed and happens in the background without any impact to application’s availability.

To get started with MemoryDB Multi-Region, you create a new multi-Region cluster and a regional cluster in one of your desired AWS Regions using AWS console, AWS SDK, or CLI. Once you create the first regional cluster, you can add up to four additional Regions to the multi-Region cluster. When data is written to any regional cluster, MemoryDB Multi-Region will automatically replicate that data to all other regional clusters within the multi-Region cluster, typically within one second. If you are using MemoryDB today, you can take a snapshot of your cluster and use it to seed a new multi-Region cluster and regional cluster.  

You can add new regional clusters to a MemoryDB Multi-Region cluster by creating regional clusters in the respective AWS Regions. However, you cannot add an existing MemoryDB cluster to an existing MemoryDB Multi-Region cluster. You can only create a new regional cluster or remove an existing regional cluster from a MemoryDB Multi-Region cluster. When you remove a regional cluster, MemoryDB Multi-Region will delete the cluster in that specific Region while maintaining the MemoryDB Multi-Region cluster. Customers can choose to add more regional clusters within the same MemoryDB Multi-Region cluster later.

MemoryDB Multi-Region provides eventual consistency because it performs asynchronous replication, which preserves in-memory speeds. Any updates made to a key in one of the MemoryDB Multi-Region regional clusters is propagated to other regional clusters asynchronously within the MemoryDB Multi-Region cluster, normally in under a second.

MemoryDB Multi-Region uses Conflict-free Replicated Data Type (CRDT) to reconcile between conflicting concurrent writes. CRDT is a data structure that can be updated independently and concurrently without coordination. The write-writer conflict is merged independently on each replica with eventual consistency.

If a Region becomes isolated or degraded, MemoryDB Multi-Region keeps track of any writes it has performed but have not yet been propagated to all of the regional clusters. When the Region comes back online, MemoryDB Multi-Region resumes propagating any pending writes from that Region to the regional clusters in other Regions. It also resumes propagating writes from other regional clusters to the Region that is now back online. MemoryDB Multi-Region propagates all previously successful writes eventually, no matter how long the Region is isolated. Conflicts can arise if your application updates the same key in different Regions at about the same time. MemoryDB Multi-Region uses Conflict-free Replicated Data Type (CRDT) reconciliation between concurrent updates. Conflict resolution is fully managed and happens in the background without any impact to an application’s availability.

MemoryDB’s throughput and latency vary based on the node type, payload size, and number of client connections. MemoryDB delivers microsecond read latency, single-digit millisecond write latency, and read-after-write latency on the primary node for a cluster shard. MemoryDB can support up to 390K read and 100K write requests per second and up to 1.3 GB/s read and 100 MB/s write throughput per node (based on internal testing on read-only and write-only workloads). A MemoryDB cluster shards data across one or more nodes, enabling you to add more shards or replicas to your cluster to increase aggregate throughput.

MemoryDB stores your entire data set in memory and uses a distributed Multi-AZ transactional log to provide data durability, consistency, and recoverability. By storing data across multiple AZs, MemoryDB has fast database recovery and restart. By also storing the data in-memory, MemoryDB can deliver ultra-fast performance and high throughput.

Yes, MemoryDB supports high availability. You can create a MemoryDB cluster with Multi-AZ availability with up to 5 replicas in different AZs. When a failure occurs on a primary node, MemoryDB will automatically failover and promote one of the replicas to serve as the new primary and direct write traffic to it. Additionally, MemoryDB utilizes a distributed transactional log to ensure the data on replicas is kept up-to-date, even in the event of a primary node failure. Failover typically happens in under 20 seconds for unplanned outages and typically under 200 milliseconds for planned outages.

MemoryDB uses a distributed transactional log to durably store data written to your database during database recovery, restart, failover, and eventual consistency between primaries and replicas.

MemoryDB leverages a distributed transactional log to durably store data. By storing data across multiple AZs, MemoryDB has fast database recovery and restart. Also, MemoryDB offers eventual consistency for replica nodes and consistent reads on primary nodes.

Valkey and Redis OSS includes an optional append-only file (AOF) feature, which persists data in a file on a primary node’s disk for durability. However, because AOF stores data locally on primary nodes in a single availability zone, there are risks for data loss. Also, in the event of a node failure, there are risks of consistency issues with replicas.

Valkey and Redis OSS allows writes and strongly consistent reads on the primary node of each shard and eventually consistent reads from read replicas. These consistency properties are not guaranteed if a primary node fails, as writes can become lost during a failover and thus violate the consistency model.

The consistency model of MemoryDB is similar to Valkey and Redis OSS. However, in MemoryDB, data is not lost across failovers, allowing clients to read their writes from primaries regardless of node failures. Only data that is successfully persisted in the multi-AZ transaction log is visible. Replica nodes are still eventually consistent, with lag metrics published to Amazon CloudWatch.

With MemoryDB version 7.0 for Redis OSS, we introduced enhanced IO multiplexing, which delivers additional improvements to throughput and latency at scale. MemoryDB version 7.2 for Valkey supports enhanced IO multiplexing as well. Enhanced IO multiplexing is ideal for throughput-bound workloads with multiple client connections, and its benefits scale with the level of workload concurrency. As an example, when using r6g.4xlarge node and running 5200 concurrent clients, you can achieve up to 46% increased throughput (read and write operations per second) and up to 21% decreased P99 latency, compared with MemoryDB version 6 for Redis OSS. For these types of workloads, a node's network IO processing can become a limiting factor in the ability to scale. With enhanced IO multiplexing, each dedicated network IO thread pipelines commands from multiple clients into the MemoryDB engine, taking advantage of the engine's ability to efficiency process commands in batches.

For more information see the documentation.

To write data to and read data from your MemoryDB cluster, you connect to your cluster using one of the supported Valkey or Redis OSS clients. For a list of supported Valkey or Redis OSS clients, please see the Valkey or Redis OSS documentation. For instructions on how to connect to your MemoryDB cluster using a Valkey or Redis OSS client, see the MemoryDB documentation. Valkey will work with existing Redis OSS clients so you don't need to change clients when you move from Redis OSS to Valkey.

You create a MemoryDB cluster with up to 500 nodes. This gives a maximum memory storage capacity of ~100 TB, assuming you have 250 primary nodes each with one replica for high availability (500 nodes total).

Yes, you can resize your MemoryDB cluster horizontally and vertically. You can scale your cluster horizontally by adding or removing nodes. You can choose to add shards to spread your dataset across more shards, and you can add additional replica nodes to each shard to increase availability and read throughput. You can also remove shards and replicas to scale-in your cluster. Additionally, you can scale your cluster vertically by changing your node type, which changes your memory and CPU resources per node. During horizontal and vertical resizing operations, your cluster continues to stay online and serve read and write requests.

MemoryDB makes maintenance and updates easy for your cluster, and provides two different processes for cluster maintenance. First, for some mandatory updates, MemoryDB automatically patches your cluster during maintenance windows which you specify. Second, for some updates, MemoryDB utilizes service updates, which you can apply at any time or schedule for a future maintenance window. Some service updates are automatically scheduled in a maintenance window after a certain date. Cluster updates help strengthen security, reliability, and operational performance of your clusters, and your cluster continues to stay online and serve read and write requests. For more information on cluster maintenance, see the MemoryDB documentation.

Yes, you create snapshots to back up the data and metadata of your MemoryDB cluster. You can manually create a snapshot, or you can use MemoryDB’s automated snapshot scheduler to take a new snapshot each day at a time you specify. You can choose to retain your snapshot for up to 35 days after it is created, and MemoryDB. Snapshots are stored in Amazon S3 which is designed for 99.999999999% (11 9's) durability. Also, you can choose to take a final snapshot of your cluster when you are deleting the cluster. Furthermore, you can export MemoryDB snapshots from the service to your Amazon S3 bucket. For more information on snapshots, see the MemoryDB documentation.

Yes, you can restore your MemoryDB cluster from a snapshot when creating a new MemoryDB cluster.

Yes, you can restore your MemoryDB cluster from a Valkey or Redis OSS RDB file. You can specify the RDB file to restore from when creating a new MemoryDB cluster.

Yes, you can migrate data from ElastiCache to MemoryDB. First, create a snapshot of your ElastiCache cluster and export it to your S3 bucket. Next, create a new MemoryDB cluster and specify the backup to restore from. MemoryDB will create a new cluster with the data and Valkey or Redis OSS metadata from the snapshot. For more information on migrating data from ElastiCache to MemoryDB, see the MemoryDB documentation.

Yes, MemoryDB offers operational and performance metrics for your cluster. MemoryDB has over 30 CloudWatch metrics, and you can view these metrics in the MemoryDB console. For more information on CloudWatch metrics and MemoryDB, see the MemoryDB documentation.

Yes, MemoryDB supports encryption of your data both at-rest and in-transit. For encryption at rest, you can use AWS Key Management Service customer managed keys (CMK) or a MemoryDB provided key. With Graviton2 instances for your MemoryDB cluster, your data is encrypted in memory using always-on 256-bit DRAM encryption.

MemoryDB uses Access Control Lists (ACLs) to control both authentication and authorization for your cluster. ACLs enable you to define different permissions for different users in the same cluster. An ACL is a collection of one or more users. Each user has a password and access string, which is used to authorize access to commands and data. To learn more about ACLs in MemoryDB, see the MemoryDB documentation.

Yes, all MemoryDB clusters must be launched in a VPC.

We will continue to support more compliance certifications. See here for the latest compliance readiness information.

Yes. To receive a history of all Amazon MemoryDB API calls made on your account, you simply turn on CloudTrail in the AWS Management Console. For more information, visit the CloudTrail home page.

Data tiering for Amazon MemoryDB is a new price-performance option for MemoryDB which automatically moves less-frequently accessed data from memory to high performance, locally attached solid-state drives (SSD). Data tiering increases capacity, simplifies cluster management, and improves total cost of ownership (TCO) for MemoryDB.

You should use data tiering when you need an easier and more cost-effective way to scale data capacity for your MemoryDB clusters without sacrificing your applications’ availability. Data tiering is ideal for workloads that access up to 20% of their data regularly, and for applications that can tolerate additional latency the first time a less-frequently accessed item is needed. Using data tiering with R6gd nodes that have nearly 5x more total capacity (memory + SSD) can help you achieve over 60% storage cost savings when running at maximum utilization, compared to R6g nodes (memory only). Assuming 500-byte String values, you can typically expect an additional 450µs latency for read requests to data stored on SSD compared to read requests to data in memory.

Data tiering works by utilizing SSD storage in cluster nodes when available memory capacity is exhausted. When using cluster nodes that have SSD storage, data tiering is automatically enabled and MemoryDB manages data placement, transparently moving items between memory and disk using a least-recently used (LRU) policy. When memory is fully consumed, MemoryDB automatically detects which items were least-recently used and moves their values to disk, optimizing cost. When an application needs to retrieve an item from disk, MemoryDB transparently moves its value to memory before serving the request, with minimal impact to performance.

To get started, create a new MemoryDB cluster using memory-optimized instances with ARM-based AWS Graviton2 processors and NVMe SSDs (R6gd). You can then migrate data from an existing cluster by importing a snapshot.

R6gd nodes with data tiering is based on per instance-hour consumed. You also pay for data written when using R6gd, similar to other MemoryDB node types. For more details, see the MemoryDB pricing page.

To get started, create a new MemoryDB cluster using memory-optimized instances with ARM-based AWS Graviton2 processors and NVMe SSDs (R6gd). You can then migrate data from an existing cluster by importing a snapshot.

MemoryDB reserved nodes offer size flexibility within a node family and AWS Region. This means that the discounted reserved node rate will be applied automatically to usage of all sizes in the same node family. For example, if you purchase a r6g.xlarge reserved node and need to scale to a larger node r6g.2xlarge, your reserved node discounted rate is automatically applied to 50% usage of the r6g.2xlarge node in the same AWS Region. The size flexibility capability will reduce the time that you need to spend managing your reserved nodes and since you’re no longer tied to a specific database node size, you can get the most out of your discount even if your capacity needs change.

MemoryDB reserved node pricing is based on node type, term duration (one- or three-year), payment option (No Upfront, Partial Upfront, All Upfront), and AWS Region. Please note that reserved node prices don't cover data written or Snapshot Storage costs. For more details, see the MemoryDB pricing page.

MemoryDB offers reserved nodes for the memory optimized R6g, R7g, and R6gd (with data tiering) nodes.

Vector search for MemoryDB supports storing millions of vectors, with single-digit millisecond query and update response times, while achieving more than 99% recall. Vector search for MemoryDB can store vectors that you generate from services such as Amazon Bedrock and Amazon SageMaker.

You should use vector search for MemoryDB when building high-speed artificial intelligence and machine learning (AI/ML) applications using the MemoryDB API. Vector search for MemoryDB is well suited to use cases where peak performance is the most important selection criteria. As of June 26, 2024, MemoryDB delivers the fastest vector search performance at the highest recall rates among popular vector databases on AWS. You can use vector search for MemoryDB to power ML and generative AI use cases such as Retrieval Augmented Generation (RAG), anomaly (fraud) detection, real-time recommendation engines, and document retrieval.

When configuring an AI/ML-driven application for speed, it can lead to poorer quality responses as measured using recall rates. Vector search for MemoryDB provides the highest throughput with single-digit millisecond query and update response times without compromising on recall by storing the vectors in memory.

With vector search, you can store, index, retrieve, and search vector embeddings within MemoryDB alongside your data. First, you generate vector embeddings directly through embedding models such as the Amazon Titan Embeddings or through managed services such as Amazon Bedrock. Then, you load the embeddings into MemoryDB after initializing your vector index using the MemoryDB data plane APIs. MemoryDB stores vector embeddings as JSON or hash data types. 

When loaded, MemoryDB builds the index with your vector embeddings. As you load new, update existing, or delete data, MemoryDB streams updates to the vector index within single-digit milliseconds. MemoryDB supports efficient search queries, prefiltering, and multiple distance metrics (cosine, dot product, and Euclidean). For more information on how to use vector search for MemoryDB, see the documentation.

There is no additional cost to use vector search for MemoryDB. Visit the MemoryDB pricing page to learn more.