Redis engine versions - Amazon MemoryDB for Redis
Redis 7.0 (enhanced)Redis 7.0 (enhanced)Redis 6.2 (enhanced)Upgrading engine versions

Redis engine versions

This section covers the supported Redis engine versions.

MemoryDB for Redis version 7.1 (enhanced)

MemoryDB for Redis version 7.1 adds support for vector search capabilities in preview for select regions, as well as critical bug fixes and performance enhancements.

  • Vector Search Feature: Vector search can be used with existing MemoryDB functionality. Applications which don't use vector search won't be affected by its presence. Vector search preview is available in MemoryDB for Redis version 7.1 onward in the following regions: US East (N. Virginia and Ohio), US West (Oregon), EU (Ireland), and Asia Pacific (Tokyo). Please refer to the documentation here for how to enable the vector search preview and related feature capabilities.

Note

MemoryDB for Redis version 7.1 is compatible with OSS Redis v7.0. For more information on the Redis 7.0 release, see Redis 7.0 Release Notes at Redis on GitHub.

MemoryDB for Redis version 7.0 (enhanced)

MemoryDB for Redis 7.0 adds a number of improvements and support for new functionality:

  • Redis Functions: MemoryDB for Redis 7 adds support for Redis Functions, and provides a managed experience enabling developers to execute LUA scripts with application logic stored on the MemoryDB cluster, without requiring clients to re-send the scripts to the server with every connection.

  • ACL improvements: MemoryDB for Redis 7 adds support for the next version of Redis Access Control Lists (ACLs). With MemoryDB for Redis 7, clients can now specify multiple sets of permissions on specific keys or keyspaces in Redis.

  • Sharded Pub/Sub: MemoryDB for Redis 7 adds support to run Redis Pub/Sub functionality in a sharded way when running MemoryDB in Cluster Mode Enabled (CME). Redis Pub/Sub capabilities enable publishers to issue messages to any number of subscribers on a channel. With Amazon MemoryDB for Redis 7, channels are bound to a shard in the MemoryDB cluster, eliminating the need to propagate channel information across shards. This results in improved scalability.

  • Enhanced I/O multiplexing: MemoryDB for Redis version 7 introduces enhanced I/O multiplexing, which delivers increased throughput and reduced latency for high-throughput workloads that have many concurrent client connections to an MemoryDB cluster. For example, when using a cluster of r6g.4xlarge nodes 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 for Redis version 6.

For more information on the Redis 7.0 release, see Redis 7.0 Release Notes at Redis on GitHub.

MemoryDB for Redis version 6.2 (enhanced)

MemoryDB introduces the next version of the Redis engine, which includes Authenticating users with Access Control Lists (ACLs), automatic version upgrade support, client-side caching and significant operational improvements.

Redis engine version 6.2.6 also introduces support for native JavaScript Object Notation (JSON) format, a simple, schemaless way to encode complex datasets inside Redis clusters. With JSON support, you can leverage the performance and Redis APIs for applications that operate over JSON. For more information, see Getting started with JSON. Also included is JSON-related metric JsonBasedCmds that is incorporated into CloudWatch to monitor the usage of this datatype. For more information, see Metrics for MemoryDB.

With Redis 6, MemoryDB will offer a single version for each Redis OSS minor release, rather than offering multiple patch versions. This is designed to minimize confusion and ambiguity on having to choose from multiple minor versions. MemoryDB will also automatically manage the minor and patch version of your running clusters, ensuring improved performance and enhanced security. This will be handled through standard customer-notification channels via a service update campaign. For more information, see Service updates in MemoryDB for Redis.

If you do not specify the engine version during creation, MemoryDB will automatically select the preferred Redis version for you. On the other hand, if you specify the engine version by using 6.2, MemoryDB will automatically invoke the preferred patch version of Redis 6.2 that is available.

For example, when you create a cluster, you set the --engine-version parameter to 6.2. The cluster will be launched with the current available preferred patch version at the creation time. Any request with a full engine version value will be rejected, an exception will be thrown and the process will fail.

When calling the DescribeEngineVersions API, the EngineVersion parameter value will be set to 6.2 and the actual full engine version will be returned in the EnginePatchVersion field.

For more information on the Redis 6.2 release, see Redis 6.2 Release Notes at Redis on GitHub.

Upgrading engine versions

MemoryDB by default automatically manages the patch version of your running clusters through service updates. You can additionally opt out from auto minor version upgrade if you set the AutoMinorVersionUpgrade property of your clusters to false. However, you can not opt out from auto patch version upgrade.

You can control if and when the protocol-compliant software powering your cluster is upgraded to new versions that are supported by MemoryDB before auto upgrade starts. This level of control enables you to maintain compatibility with specific versions, test new versions with your application before deploying in production, and perform version upgrades on your own terms and timelines.

You can initiate engine version upgrades to your cluster in the following ways:

Note the following:

  • You can upgrade to a newer engine version, but you can't downgrade to an older engine version. If you want to use an older engine version, you must delete the existing cluster and create it anew with the older engine version.

  • We recommend periodically upgrading to the latest major version, since most major improvements are not back ported to older versions. As MemoryDB expands availability to a new AWS Region, MemoryDB supports the two most recent MAJOR.MINOR versions at that time for the new Region. For example, if a new AWS region launches and the latest MAJOR.MINOR MemoryDB for Redis versions are 7.0 and 6.2, MemoryDB for Redis will support versions 7.0 and 6.2 in the new AWS Region. As newer MAJOR.MINOR versions of MemoryDB for Redis are released, MemoryDB will continue to add support for the newly released MemoryDB for Redis Versions. To learn more about choosing Regions for MemoryDB, see Supported Regions & endpoints.

  • Engine version management is designed so that you can have as much control as possible over how patching occurs. However, MemoryDB reserves the right to patch your cluster on your behalf in the unlikely event of a critical security vulnerability in the system or software.

  • MemoryDB will offer a single version for each Redis OSS minor release, rather than offering multiple patch versions. This is designed to minimize confusion and ambiguity on having to choose from multiple versions. MemoryDB will also automatically manage the minor and patch version of your running clusters, ensuring improved performance and enhanced security. This will be handled through standard customer-notification channels via a service update campaign. For more information, see Service updates in MemoryDB for Redis.

  • You can upgrade your cluster version with minimal downtime. The cluster is available for reads during the entire upgrade and is available for writes for most of the upgrade duration, except during the failover operation which lasts a few seconds.

  • We recommend that you perform engine upgrades during periods of low incoming write traffic.

    Clusters with multiple shards are processed and patched as follows:

    • Only one upgrade operation is performed per shard at any time.

    • In each shard, all replicas are processed before the primary is processed. If there are fewer replicas in a shard, the primary in that shard might be processed before the replicas in other shards are finished processing.

    • Across all the shards, primary nodes are processed in series. Only one primary node is upgraded at a time.

How to upgrade engine versions

You initiate version upgrades to your cluster by modifying it using the MemoryDB console, the AWS CLI, or the MemoryDB API and specifying a newer engine version. For more information, see the following topics.

Resolving blocked Redis engine upgrades

As shown in the following table, your Redis engine upgrade operation is blocked if you have a pending scale up operation.

Pending operations Blocked operations
Scale up Immediate engine upgrade
Engine upgrade Immediate scale up
Scale up and engine upgrade Immediate scale up
Immediate engine upgrade