MemoryDB

Introduction

Amazon MemoryDB is a fully managed, in-memory database service designed for ultra-fast, primary database use cases. Compatible with both Valkey and Redis OSS, it improves performance and durability.

Built for the AWS cloud environment, MemoryDB simplifies the deployment and operation of in-memory databases, acting as a replacement for using a cache in front of a database.

LocalStack provides support for the main MemoryDB APIs surrounding cluster creation, allowing developers to utilize the MemoryDB functionalities in their local development environment. The supported APIs are available on our API Coverage section, which provides information on the extent of MemoryDB’s integration with LocalStack.

Getting started

This guide is designed for users new to MemoryDB and assumes basic knowledge of the AWS CLI and our awslocal wrapper script.

Start your LocalStack container using your preferred method. We will demonstrate how you can create a MemoryDB cluster and connect to it.

Basic cluster creation

You can create a MemoryDB cluster using the CreateCluster API. Run the following command to create a cluster:

awslocal memorydb create-cluster \
  --cluster-name my-redis-cluster \
  --node-type db.t4g.small \
  --acl-name open-access

Once it becomes available, you will be able to use the cluster endpoint for Redis operations. Run the following command to retrieve the cluster endpoint using the DescribeClusters API:

awslocal memorydb describe-clusters --query "Clusters[0].ClusterEndpoint"

Output

{
  "Address": "127.0.0.1",
  "Port": 36739
}

The cache cluster uses a random port of the external service port range in regular execution and a port between 36739 and 46738 in container mode. Use this port number to connect to the Redis instance using the redis-cli command line tool:

redis-cli -p 4510 ping
PONG
redis-cli -p 4510 set foo bar
OK
redis-cli -p 4510 get foo
"bar"

You can also check the cluster configuration using the cluster nodes command:

redis-cli -c -p 4510 cluster nodes

Container mode

To start Redis clusters of a specific version, enable container mode for Redis-based services in LocalStack. This approach directs LocalStack to launch Redis instances in distinct containers, utilizing your chosen image tag. Additionally, container mode is beneficial for independently examining the logs of each Redis instance. To activate this, set the REDIS_CONTAINER_MODE configuration variable to 1.

Valkey Engine

LocalStack offers the additional option to use Valkey as an alternative to Redis in Amazon MemoryDB.

To enable full Valkey emulation:

1. Start LocalStack with Valkey support enabled by setting the environment variable, REDIS_CONTAINER_MODE=1
2. Create a cluster with the Valkey engine by including the --engine valkey flag in your API call:

awslocal memorydb create-cluster \
  --cluster-name my-valkey-cluster \
  --node-type db.t4g.small \
  --acl-name open-access \
  --engine valkey

Valkey support includes:

• The ability to specify valkey as the engine when creating Amazon MemoryDB clusters.

• Automatic mapping of each engine to a default supported version (Redis 7.2.10, Valkey 7.2.10), ensuring DockerHub compatibility.

• Support for the Engine and EngineVersion fields in the CreateCluster API, which now recognize and handle valkey.

Note

A Valkey cluster can only be started when container mode is enabled.

Current Limitations

LocalStack’s emulation support for MemoryDB primarily focuses on the creation and termination of Redis servers in cluster mode.

Essential resources for running a cluster, such as parameter groups, security groups, and subnet groups, are mocked but have no effect on the Redis servers’ operation.

LocalStack currently doesn’t support MemoryDB snapshots, failovers, users/passwords, service updates, replication scaling, SSL, migrations, service integration (like CloudWatch/Kinesis log delivery, SNS notifications) or tests.

At present, LocalStack does not support features such as:

• MemoryDB snapshots
• Failovers
• User/password management
• Service updates
• Replication scaling
• SSL
• Migrations
• Service integration (e.g., CloudWatch/Kinesis log delivery, SNS notifications) or facilitate related testing.

API Coverage

Operation ▲	Implemented	Image

PreviousPage 1 of 0Next