Valkey 9.1 for Operators: What Changed and How to Upgrade

Valkey 9.1.0 went GA on 19 May 2026, and the current patch is 9.1.3 (26 October 2026). If you run Valkey 8.0 or 8.1, the upgrade is still a rolling binary swap: replicas first, then a manual failover per shard. The work is in what changes underneath. A 9.x node writes RDB files with a VALKEY080 header that Valkey 8.0 cannot read at all. Releases 9.1.0 to 9.1.2 can reject some data written by 8.x and 9.0, which shows up as failed RDB loads and failed full syncs, because of a listpack encoding bug fixed in 9.1.3. You also skip everything Valkey 9.0 introduced. This guide covers the 9.0 and 9.1 changes to plan for, the CVEs fixed since 9.1.1, a rolling upgrade runbook, and how far you can roll back.

Scope and review date: November 2026. This post covers self-managed Valkey 8.0 and 8.1 standalone, Sentinel, and cluster deployments moving to Valkey 9.1, with a note on Amazon ElastiCache. Versions, defaults, and commands were checked against the Valkey release notes, documentation, and source tags on 9 November 2026. They were not run in a lab, so rehearse them on staging.

Which Valkey 9.1 release should you run?

The Valkey 9.1 announcement is dated 19 May 2026. Since then the GitHub releases page lists three patch releases, all marked upgrade urgency SECURITY:

The listpack fix decides the target. Pull request #4819 explains that for entries whose encoded length is exactly 16383, 2097151, or 268435455 bytes, Valkey wrote one backlen width up to 9.0 and a narrower one in 9.1.0 through 9.1.2. A 16378-byte string element is enough to hit it. Those 9.1 releases reject such data on load, so a 9.1.0 replica doing a full sync from an 8.x or 9.0 primary can fail. Use 9.1.3 or a later patch.

# Record the version of every node before you start
for h in node1 node2 node3; do
  valkey-cli -h "$h" INFO server | grep -E '^(valkey_version|redis_version|server_mode)'
done

Interpretation: track upgrades by valkey_version. redis_version stays at 7.2.4 on every Valkey release; the source calls it a Redis OSS compatibility version that "should never exceed 7.2.x".

What changes between Valkey 8.1 and 9.1?

An 8.x deployment skips the whole 9.0 release (GA 21 October 2025) as well as 9.1. Valkey has no feature compatibility version: behaviour changes arrive with the binary, and new data formats arrive when you use a new feature. Sources for the table are the Valkey 9.0 announcement, the 9.0 and 9.1 release notes, and the shipped valkey.conf and config.c at tags 8.1.11 and 9.1.3.

Behaviour changes worth a test

• Authentication first. Valkey 9.0 moved the auth check in front of the command-exists, arity, and protected-mode checks (#1475). An unauthenticated client sending an unknown command now gets an auth error instead of an unknown-command error.
• Stricter protocol parsing. 9.1.0-rc1 (and 9.0.5) reject requests without strict CRLF terminators with a protocol error instead of misparsing them. Hand-written RESP clients and health-check scripts are the usual suspects.

How do database-level ACLs work in Valkey 9.1?

Before 9.1, an ACL user who could run a command on a key could do it in any numbered database. The Valkey ACL documentation now lists three rules. db=<id>[,<id>...] allows only the listed databases and replaces any earlier list. alldbs allows every database and is the default for new users and selectors. resetdbs removes all database access.

A denied database returns a NOPERM error and an ACL LOG entry with the reason database. The 9.1 announcement shows the client side:

> SELECT 2
(error) NOPERM No permissions to access database

Interpretation: new connections still land in database 0, even for users who cannot use it, so set the database in the client's connection options.

The docs list which commands are checked against the database list. SELECT, SWAPDB, MOVE, and COPY ... DB need access to every database id they name. FLUSHALL, CLUSTER MIGRATESLOTS, and CLUSTER CANCELSLOTMIGRATIONS need alldbs, because they touch every database. Selectors can give different rights per database:

# Writes in databases 0 and 1, reads only in 2 and 3 (from the ACL docs)
ACL SETUSER bob on nopass (db=0,1 +@write +select ~*) (db=2,3 +@read +select ~*)
ACL LOG 10

Interpretation: a command runs if the root permissions or any selector allow it. Watch ACL LOG after tightening a user; denials show up there first.

What does moving Lua into a module change?

From the application's side, nothing: pull request #2858 states that EVAL and FUNCTION/FCALL behave as before. The change is in packaging. 9.1.0-rc2 made static linking the default, so a standard build still has Lua with no loadmodule line. The 9.1.3 README documents make BUILD_LUA=no to build a server without Lua, which removes the scripting attack surface if you never use scripts.

valkey-cli INFO "scripting engines"

Interpretation: the section starts with engines_count, engines_total_used_memory, and engines_total_memory_overhead, then a line per engine. Without Lua, engines_count is 0 and EVAL fails, so check that no client library or job queue uses scripts first.

The module move has a security history worth knowing. GHSA-fq2f-crmw-q97r, fixed in 9.1.2, was a use-after-free in the Lua debugger "introduced when the Lua scripting engine was moved into a Valkey module"; the 8.0 and 8.1 lines are not affected. If you cannot patch, the advisory's mitigation is to deny SCRIPT DEBUG with an ACL rule such as -script|debug, which leaves EVAL and EVALSHA working.

What changed in Valkey 9.1 I/O threading?

Valkey keeps command execution on the main thread. I/O threads read sockets, parse requests, and write replies. In the 8.x design the main thread assigned each job to a specific I/O thread. Pull request #3324, shipped in 9.1.0-rc2, replaces that with lock-free queues: one shared queue that any idle I/O thread pulls from, one response queue back to the main thread, and a private queue per thread for jobs that must run on that thread, such as freeing memory it allocated.

Valkey reports up to 17% higher throughput from the redesign in its own benchmarks; measure your workload. Two operational changes matter more. Since 9.0, io-threads can be changed at runtime (8.1 fixes it at startup). And 9.1 adds active-time counters, because a busy-polling thread shows near 100% CPU even when idle.

# 9.x: change thread count without a restart, then read real thread load
valkey-cli CONFIG SET io-threads 6
valkey-cli INFO cpu | grep -E 'used_active_time_(main_thread|io_thread_[0-9]+)'

Interpretation: the counters are cumulative seconds of active work; sample twice and divide the difference by the interval. If used_active_time_main_thread grows almost as fast as wall-clock time, the main thread is the bottleneck and more I/O threads will not help.

Will Redis OSS clients and configs keep working on Valkey 9.1?

Clients, yes, for the commands they already use. The Valkey migration guide says Valkey is compatible with Redis OSS 7.2 and earlier, and the clients page says anything that speaks the Redis 7.2 wire protocol works. New commands (CLUSTERSCAN, MSETEX, HGETDEL, the field-TTL family) need client support before typed APIs expose them, though most clients can send raw commands. Using SELECT in cluster mode depends on your client allowing it; test that before raising cluster-databases.

Config files move forward without edits, but 9.x-only directives move one way. These exist in 9.1.3's valkey.conf and not in 8.1.11's:

# 9.x-only directives or values: 8.x does not know them, so expect it to refuse to start
cluster-databases 1               # 9.0+, immutable, default 1
hash-seed example-seed-val        # 9.1, immutable; stable SCAN order across nodes
tls-auto-reload-interval 86400    # 9.1, default 0 (no automatic reload)
cluster-config-save-behavior sync # 9.1, or best-effort
log-format json                   # json value is new in 9.1; legacy and logfmt exist in 8.1
shutdown-on-sigterm failover      # failover flag is 9.0+

Interpretation: keep a copy of the 8.x config for rollback, and add these only after the burn-in. cluster-config-save-behavior best-effort keeps a node running when it cannot save nodes.conf; the config file warns that a restart may then load stale cluster state.

Which CVEs were fixed in Valkey 9.1.1 and later?

Every advisory below is published on the Valkey security advisories page. The fixes were also released for the 9.0, 8.1, and 8.0 lines, so patching 8.x is not a reason to rush the major upgrade.

How do you run a rolling Valkey cluster upgrade from 8.x to 9.1?

The Valkey cluster tutorial sets the order per shard: upgrade the replicas, wait for them to catch up, run CLUSTER FAILOVER on an upgraded replica, then upgrade the old primary.

The manual failover waits up to cluster-manual-failover-timeout (default 5000 ms) for the replica to catch up. If it times out, the primary resumes, so check offsets and retry.

# After each shard
valkey-cli -h 10.0.0.21 CLUSTER NODES | grep master
valkey-cli --cluster check 10.0.0.21:6379

Interpretation: the check must report all 16384 slots covered before you start the next shard.

Sentinel and standalone deployments

The Valkey administration guide gives the same pattern for Sentinel: upgrade replicas one after the other, fail over to an upgraded replica, then upgrade the old primary. Upgrade the Sentinel processes one at a time too. For a standalone server, the guide starts the new version as a replica, waits for the sync, switches clients, and promotes it.

valkey-cli -p 26379 SENTINEL FAILOVER mymaster
valkey-cli -p 26379 SENTINEL GET-MASTER-ADDR-BY-NAME mymaster

Interpretation: the second command must return an upgraded replica's address before you touch the old primary.

On Amazon ElastiCache, AWS announced Valkey 9.1 support for node-based clusters on 23 June 2026. The rollback advice below still applies.

How far can you roll back from Valkey 9.1 to 8.x?

There is no feature-compatibility switch, so the answer depends on the data. Three facts from the source and config files set the limits:

• 8.0 cannot read a 9.x RDB file. The 8.0.12 loader accepts only the REDIS signature, and 9.x writes VALKEY080.
• 8.1 can try, best effort. 8.1 has rdb-version-check, default strict. Set to relaxed, it attempts a newer RDB file and, as valkey.conf says, aborts if it meets unknown information.
• A 9.x primary can feed an older replica. In rdb.h at 9.1.3, Valkey maps RDB 11 to 7.2 and RDB 80 to 9.0, and replication picks the format the replica supports. A hash with field TTLs cannot be written as RDB 11, so that sync fails.

# Before any rollback: is there 9.x-only state?
valkey-cli CONFIG GET cluster-databases
valkey-cli ACL LIST | grep -E 'db=|resetdbs'
valkey-cli INFO commandstats | grep -E 'cmdstat_(hexpire|hpexpire|hsetex|hgetex)'

Interpretation: any cluster-databases value above 1 or any db= rule blocks a clean return to 8.x. Nonzero calls for the field-TTL commands mean some hashes may carry field TTLs. The counters reset on restart, so the reliable control is an application flag that keeps those commands unused during the burn-in. Explicit db= rules are 9.1 syntax; 9.1.1 only stopped writing the implicit alldbs.

Frequently asked questions

Key takeaways

Plan your Valkey 9.1 upgrade with JusDB

JusDB's Valkey support team can review your 8.x deployment against the 9.0 and 9.1 changes, check client libraries and ACL rules, and write a rolling upgrade runbook with a rehearsed rollback path for your Sentinel or cluster topology.

Bring your node versions, topology, ACL file, and maintenance windows. Your team approves every production change.

Related reading

• Redis 8 vs Valkey 8 in production
• Valkey performance tuning: memory, persistence, and cluster config
• Redis Cluster: setup, resharding, and operational guide
• Valkey 9.1.0-rc1 release notes on GitHub