Supported engines and versions

• New WITHSCORE option for ZRANK and ZREVRANK commands

• CLIENT NO-TOUCH for clients to run commands without affecting LRU/LFU of keys.

• New command CLUSTER MYSHARDID that returns the Shard ID of the node to logically group nodes in cluster mode based on replication.

• Performance and memory optimizations for various data types.

• When calling PUBLISH with a RESP3 client that's also subscribed to the same channel, the order is changed and the reply is sent before the published message.

• Client side tracking for scripts now tracks the keys that are read by the script, instead of the keys that are declared by the caller of EVAL / FCALL.

• Freeze time sampling occurs during command execution and in scripts.

• When a blocked command is being unblocked, checks such as ACL, OOM, and others are re-evaluated.

• ACL failure error message text and error codes are unified.

• A blocked stream command that's released when key no longer exists carries a different error code (-NOGROUP or -WRONGTYPE instead of -UNBLOCKED).

• The command stats are updated for blocked commands only when the command actually executes.

• The internal storage of ACL users no longer removes redundant command and category rules. This may alter the way those rules are displayed as part of ACL SAVE, ACL GETUSER and ACL LIST.

• Any client connections created for TLS-based replication use SNI if possible.

• XINFO STREAM: The seen-time response field now denotes the last attempted interaction instead of the last successful interaction. The new active-time response field now denotes the last successful interaction.

• XREADGROUP and X[AUTO]CLAIM create the consumer regardless of whether it was able to perform some reading/claiming.

• ACL default newly created user set sanitize-payload flag in ACL LIST/GETUSER.

• The HELLO command does not affect the client state unless successful.

• NAN replies are normalized to a single nan type, similar to the current behavior of inf.

• ElastiCache (Redis OSS) version 7.1 (enhanced)

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

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

• Sharded Pub/Sub: ElastiCache with Valkey and Redis OSS 7 adds support to run Pub/Sub functionality in a sharded way when running ElastiCache in Cluster Mode Enabled (CME). Pub/Sub capabilities enable publishers to issue messages to any number of subscribers on a channel. Channels are bound to a shard in the ElastiCache cluster, eliminating the need to propagate channel information across shards resulting in improved scalability.

• Enhanced I/O multiplexing: ElastiCache with Valkey and Redis OSS 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 ElastiCache cluster. For example, when using a cluster of r6g.xlarge nodes and running 5200 concurrent clients, you can achieve up to 72% increased throughput (read and write operations per second) and up to 71% decreaseed P99 latency, compared with ElastiCache with Redis OSS version 6.

• Engine stability guarantee in special conditions.

• Improved Hyperloglog error handling.

• Enhanced handshake commands for reliable replication.

• Consistent message delivery tracking via XCLAIM command.

• Improved LFU field management in objects.

• Enhanced transaction management when using ZPOP.

• Ability to rename commands: A parameter called rename-commands that allows you to rename potentially dangerous or expensive Redis OSS commands that might cause accidental data loss, such as FLUSHALL or FLUSHDB. This is similar to the rename-command configuration in open source Redis OSS. However, ElastiCache has improved the experience by providing a fully managed workflow. The command name changes are applied immediately, and automatically propagated across all nodes in the cluster that contain the command list. There is no intervention required on your part, such as rebooting nodes.

  The following examples demonstrate how to modify existing parameter groups. They include the rename-commands parameter, which is a space-separated list of commands you want to rename:

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall'" --region region
  

  In this example, the rename-commands parameter is used to rename the flushall command to restrictedflushall.

  To rename multiple commands, use the following:

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall flushdb restrictedflushdb''" --region region
  

  To revert any change, re-run the command and exclude any renamed values from the ParameterValue list that you want to retain, as shown following:

  aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
  --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall restrictedflushall'" --region region
  

  In this case, the flushall command is renamed to restrictedflushall and any other renamed commands revert to their original command names.

  Note

  When renaming commands, you are restricted to the following limitations:

  • All renamed commands should be alphanumeric.

  • The maximum length of new command names is 20 alphanumeric characters.

  • When renaming commands, ensure that you update the parameter group associated with your cluster.

  • To prevent a command's use entirely, use the keyword blocked, as shown following:

    aws elasticache modify-cache-parameter-group --cache-parameter-group-name custom_param_group
    --parameter-name-values "ParameterName=rename-commands,  ParameterValue='flushall blocked'" --region region
    

  For more information on the parameter changes and a list of what commands are eligible for renaming, see Redis OSS 5.0.3 parameter changes.

• Redis OSS Streams: This models a log data structure that allows producers to append new items in real time. It also allows consumers to consume messages either in a blocking or nonblocking fashion. Streams also allow consumer groups, which represent a group of clients to cooperatively consume different portions of the same stream of messages, similar to Apache Kafka. For more information, see Streams.

• Support for a family of stream commands, such as XADD, XRANGE and XREAD. For more information, see Streams Commands.

• A number of new and renamed parameters. For more information, see Redis OSS 5.0.0 parameter changes.

• A new Redis OSS metric, StreamBasedCmds.

• Slightly faster snapshot time for Redis OSS nodes.

• Engine stability guarantee in special conditions.

• Improved Hyperloglog error handling.

• Enhanced handshake commands for reliable replication.

• Consistent message delivery tracking via XCLAIM command.

• Improved LFU field management in objects.

• Enhanced transaction management when using ZPOP.

• Redis OSS Streams: This models a log data structure that allows producers to append new items in real time. It also allows consumers to consume messages either in a blocking or nonblocking fashion. Streams also allow consumer groups, which represent a group of clients to cooperatively consume different portions of the same stream of messages, similar to Apache Kafka. For more information, see Streams.

• Support for a family of stream commands, such as XADD, XRANGE and XREAD. For more information, see Streams Commands.

• A number of new and renamed parameters. For more information, see Redis OSS 5.0.0 parameter changes.

• A new Redis OSS metric, StreamBasedCmds.

• Slightly faster snapshot time for Redis OSS nodes.

• Both online cluster resizing and encryption in a single ElastiCache (Redis OSS) version. For more information, see the following:

  • Scaling clusters in Valkey or Redis OSS (Cluster Mode Enabled)

  • Online resharding for Valkey or Redis OSS (cluster mode enabled)

  • Data security in Amazon ElastiCache

• A number of new parameters. For more information, see Redis OSS 4.0.10 parameter changes.

• Support for family of memory commands, such as MEMORY. For more information, see Commands (search on MEMO).

• Support for memory defragmentation while online thus allowing more efficient memory utilization and more memory available for your data.

• Support for asynchronous flushes and deletes. ElastiCache (Redis OSS) supports commands like UNLINK, FLUSHDB and FLUSHALL to run in a different thread from the main thread. Doing this helps improve performance and response times for your applications by freeing memory asynchronously.

• A new Redis OSS metric, ActiveDefragHits. For more information, see Metrics for Redis OSS.

• Online resharding for Valkey or Redis OSS (cluster mode enabled)

• Online cluster resizing

• ElastiCache in-transit encryption (TLS)

• At-Rest Encryption in ElastiCache

• Compliance validation for Amazon ElastiCache

Notes:

• Partitioning – the ability to split your data across 2 to 500 node groups (shards) with replication support for each node group.

• Geospatial indexing – Redis OSS 3.2.4 introduces support for geospatial indexing via six GEO commands. For more information, see the Redis OSS GEO* command documentation Commands: GEO on the Valkey Commands page (filtered for GEO).

• Replica migration

• Cluster rebalancing

• Lua debugger

• cluster meet

• cluster replicate

• cluster flushslots

• cluster addslots

• cluster delslots

• cluster setslot

• cluster saveconfig

• cluster forget

• cluster failover

• cluster bumpepoch

• cluster set-config-epoch

• cluster reset

• Support for forkless backups and synchronizations, which allows you to allocate less memory for backup overhead and more for your application. For more information, see How synchronization and backup are implemented. The forkless process can impact both latency and throughput. When there is high write throughput, when a replica re-syncs, it can be unreachable for the entire time it is syncing.

• If there is a failover, replication groups now recover faster because replicas perform partial syncs with the primary rather than full syncs whenever possible. Additionally, both the primary and replicas no longer use the disk during syncs, providing further speed gains.

• Support for two new CloudWatch metrics.

  • ReplicationBytes – The number of bytes a replication group's primary cluster is sending to the read replicas.

  • SaveInProgress – A binary value that indicates whether or not there is a background save process running.

  For more information, see Monitoring use with CloudWatch Metrics.

• A number of critical bug fixes in replication PSYNC behavior. For more information, see Redis OSS 2.8 release notes.

• To maintain enhanced replication performance in Multi-AZ replication groups and for increased cluster stability, non-ElastiCache replicas are no longer supported.

• To improve data consistency between the primary cluster and replicas in a replication group, the replicas no longer evict keys independent of the primary cluster.

• Redis OSS configuration variables appendonly and appendfsync are not supported on Redis OSS version 2.8.22 and later.

• In low-memory situations, clients with a large output buffer might be disconnected from a replica cluster. If disconnected, the client needs to reconnect. Such situations are most likely to occur for PUBSUB clients.

• Support for HyperLogLog. For more information, see Redis OSS new data structure: HyperLogLog.

• The sorted set data type now has support for lexicographic range queries with the new commands ZRANGEBYLEX, ZLEXCOUNT, and ZREMRANGEBYLEX.

• To prevent a primary node from sending stale data to replica nodes, the master SYNC fails if a background save (bgsave) child process is aborted.

• Support for the HyperLogLogBasedCommands CloudWatch metric. For more information, see Metrics for Valkey and Redis OSS.

• Improved resiliency and fault tolerance for read replicas.

• Support for partial resynchronization.

• Support for user-defined minimum number of read replicas that must be available at all times.

• Full support for pub/sub—notifying clients of events on the server.

• Automatic detection of a primary node failure and failover of your primary node to a secondary node.

• Automated slab rebalancing.

• Faster hash table lookups with murmur3 algorithm.

• Segmented LRU algorithm.

• LRU crawler to background-reclaim memory.

• --enable-seccomp: A compile-time option.

• Cumulative fixes, such as ASCII multigets, CVE-2017-9951 and limit crawls for metadumper.

• Better connection management by closing connections at the connection limit.

• Improved item-size management for item size above 1MB.

• Better performance and memory-overhead improvements by reducing memory requirements per-item by a few bytes.

• Ability to dump all of the metadata for a particular slab class, a list of slab classes, or all slab classes. For more information, see Memcached 1.4.31 Release Notes.

• Improved support for large items over the 1 megabyte default. For more information, see Memcached 1.4.29 Release Notes.

• Ability to specify how long a client can be idle before being asked to close.

  Ability to dynamically increase the amount of memory available to Memcached without having to restart the cluster. For more information, see Memcached 1.4.27 Release Notes.

• Logging of fetchers, mutations, and evictions are now supported. For more information, see Memcached 1.4.26 Release Notes.

• Freed memory can be reclaimed back into a global pool and reassigned to new slab classes. For more information, see Memcached 1.4.25 Release Notes.

• Several bug fixes.

• Some new commands and parameters. For a list, see Memcached 1.4.33 added parameters.

• Least recently used (LRU) management using a background process.

• Added the option of using jenkins or murmur3 as your hash algorithm.

• Some new commands and parameters. For a list, see Memcached 1.4.24 added parameters.

• Several bug fixes.

• Enhanced slab rebalancing capability.

• Performance and scalability improvement.

• Introduced the touch command to update the expiration time of an existing item without fetching it.

• Auto discovery—the ability for client programs to automatically determine all of the cache nodes in a cluster, and to initiate and maintain connections to all of these nodes.