Can't handle RDB format version 12

Symptom

The container exits right after start; the log ends with:

* Server initialized
# Can't handle RDB format version 12
# Fatal error loading the DB, check server logs. Exiting.

With AOF enabled (appendonly yes, which in Redis 7 writes an RDB "base" file):

* Reading RDB base file on AOF loading...
# Can't handle RDB format version 12
# Error reading the RDB base file appendonly.aof.2.base.rdb, AOF loading aborted

Under Compose/Kubernetes this shows up as a restart loop of the cache service.

When it happens

The data volume was last written by Redis 7.4.x (RDB format version 12 — the file starts with the bytes REDIS0012), and you start an older or non-Redis server on the same volume:

• valkey/valkey:8-alpine / 8.1-alpine (8.1.10 at the time of testing) — fails;
• redis:7.2-alpine (7.2.16) — fails;
• valkey/valkey:9-alpine (9.1.2) with default settings — fails.

Typical triggers: switching the image tag from redis:7.4 to valkey/valkey:8 for licensing reasons, a rollback of the Redis version, or restoring a backup taken from a 7.4 server onto 7.2.

Check the file header to know what you have:

head -c 9 dump.rdb; echo      # REDIS0012 = Redis 7.4 ; REDIS0011 = Redis 7.2 / Valkey 8 ; VALKEY080 = Valkey 9 native

Cause

Each server refuses RDB versions newer than the one it writes. Redis 7.4 bumped the format to 12; Valkey forked from Redis 7.2.4 (format 11) and never adopted 12, so Valkey 8.x cannot read it. The same version gate applies to every path that transfers RDB payloads, not only files on disk.

Fix

Pick one:

1. The data is a cache you can rebuild (sessions you can expire, rate-limit counters, memoized lookups): remove dump.rdb and appendonlydir/ from the volume (or use a new volume) and start the new server empty. This is what most app caches should do.
2. Stay on the writer's version: pin redis:7.4-alpine (not redis:latest/redis:alpine, which move) until you migrate deliberately.
3. Move to Valkey 9 with relaxed checking: Valkey 9.1.2 loads a Redis 7.4 file when started with

   valkey-server --rdb-version-check relaxed

Observed log: Loading RDB produced by Redis version 7.4.11 … Done loading RDB, keys loaded: 3 and the data (string, list, hash) read back correctly. After the next SAVE the file header is VALKEY080 — a one-way door; Redis can no longer read it. Take a copy of the original file first.

1. Logical copy: read each key by type on the old server and write it on the new one (a SCAN-based copier or a migration tool that re-issues commands, not one that ships RDB/DUMP payloads).

Verify

docker run -d --name old -v "$PWD/data:/data" redis:7.4-alpine
docker exec old redis-cli RPUSH l a b c; docker exec old redis-cli SAVE; docker rm -f old
head -c 9 data/dump.rdb; echo                          # REDIS0012
docker run --rm -v "$PWD/data:/data" valkey/valkey:9-alpine \
  sh -c 'valkey-server --dir /data --rdb-version-check relaxed & sleep 2; valkey-cli LRANGE l 0 -1'
# a b c

After option 1, docker logs <cache> should show Ready to accept connections and no RDB format line.

Notes (what did not work)

• --rdb-version-check relaxed on Valkey 8.1.10: the option exists (default strict) but the load still failed with the same message.
• MIGRATE/DUMP+RESTORE from Redis 7.4 to Valkey 8: ERR Target instance replied with error: ERR DUMP payload version or checksum are wrong. DUMP payloads carry the same RDB version.
• Replication (REPLICAOF <redis-7.4> on Valkey 8): full sync loops with Failed trying to load the PRIMARY synchronization DB from disk and Discarding the half-loaded data; master_link_status:down, 0 keys.
• Turning AOF on in the new server does not bypass it: the AOF base file is RDB 12 too.
• Whether a given Valkey 8.x patch release differs was not checked beyond 8.1.10; re-test your exact tag.