Amazon MemoryDB FAQs

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.

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.

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.

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.