Products
Redis migration support and evidence
Reviewed 2026-10-26 UTC against the 1.82.1 source baseline and current retained Redis qualification records. The documentation patch is 1.82.2. Match your deployed image and live API before running a migration. This page describes implemented behavior and the scope of available evidence; it does not certify every recognized command or topology for production cutover.
Endpoint, protocol and command boundaries
Redis/Valkey same-family migrations use Redis-compatible historical key movement and live routing. Historical copy uses SCAN with DUMP/RESTORE and TTL handling. Validate the exact source/target versions, RDB serialization, data types, modules, ACLs, TLS settings and topology. Ordinary Redis key movement does not migrate RediSearch/vector index definitions as a provider-neutral vector migration.
The generated command catalog lists every recognized command and typed REST input. Recognition means Eden has a command declaration; execution also depends on the backend, permissions, route and connection mode. RESP2/RESP3 framing support does not imply that every push, stateful command or server module is supported in a migration.
| Command/session family | Ordinary gateway route | Active migration boundary |
|---|---|---|
| String, hash, list, set, sorted-set and ordinary key operations | Declared commands dispatch subject to policy/backend support | Use exact command-mix validation; effectful writes need independent delivery/order checks |
| Pipelines | Bounded command/response handling | Preserve per-command results; incomplete response counts create delivery uncertainty, not successful replay |
WATCH, MULTI, EXEC, DISCARD, UNWATCH | Transaction-pinned connection path with ownership/drain gates | WATCH and MULTI are rejected for replicated writes; do not assume cross-backend atomicity |
BLPOP, BRPOP, BRPOPLPUSH, BLMOVE, BLMPOP, BZPOPMIN, BZPOPMAX, BZMPOP | Dedicated exclusive lease; native multi-key execution and same-shard keys required | Blocking forms rejected before dispatch on migration routes |
XREAD, XREADGROUP with BLOCK | Dedicated exclusive lease; consumer-group delivery is effectful | Blocking forms rejected; no automatic retry after an uncertain response |
WAIT, WAITAOF | Rejected because they require the caller's existing backend socket | Rejected |
SUBSCRIBE, PSUBSCRIBE, SSUBSCRIBE and unsubscribe variants | Dedicated Pub/Sub stream; sharded subscription requires Redis/Valkey 7+ | Rejected; route/migration changes terminate existing sessions without lossless replay/resubscription |
AUTH, SELECT from a native gateway client | Rejected on the ordinary proxy command path; backend authentication/database selection comes from endpoint configuration | Do not use client AUTH/SELECT to change a migration connection's identity |
Virtual-cluster HELLO, AUTH, SELECT, ASKING, READONLY, READWRITE, RESET | Cluster routing has local session-control replies; SELECT accepts database 0 and HELLO accepts RESP 2/3 | Local AUTH acknowledgement is not backend credential verification; use the configured Eden access boundary and endpoint credentials |
PSYNC, REPLCONF | Dedicated standalone replication contract with validated negotiation and length-delimited RDB | Replication rejected during migration and virtual-cluster routing |
Legacy SYNC | Rejected; use the supported PSYNC contract | Rejected |
| Lua/functions, administrative and module commands | Catalog/backend support and command policy apply | Independently validate nondeterminism, side effects, keys and target compatibility; registry membership is insufficient |
| Tracking, MONITOR and other persistent connection state | Do not assume ordinary pooled request execution preserves client state | No blanket migration qualification is established by the command catalog |
BLOCK 0 is still bounded by the caller deadline. Cancellation after dispatch discards the dedicated socket and does not establish that an effectful command did nothing. Newer blocking commands require discovered compatible server metadata; metadata absence is not permission to send them optimistically.
Managed Redis and topology
The Elasticache endpoint kind identifies provider-owned Redis behavior; a Valkey banner alone does not. Optional probes expose supported, unsupported, permission_denied, unknown or provider_owned. Eden avoids provider-owned CONFIG probes and uses bounded INFO/CLUSTER discovery where appropriate. Unavailable maxclients or memory capacity is reported as unavailable, not zero utilization. Cluster discovery distinguishes Enabled, Disabled and Unknown. Unknown topology blocks migration until established.
Verify the production node inventory and distinguish slot-owning primaries from replicas. Historical copy maps to primaries; exposed listeners and client routing can include both. A diagram with 72 lanes is a sizing example, not a 72-node or 120-node qualification result. In HA, lane ownership epochs and all-participant stage confirmations supplement normal migration preflight; see HA Redis migrations.
Current evidence and its limits
| Evidence reviewed | What it establishes | What it does not establish |
|---|---|---|
| Command registry, parser/encoder and transaction wire checks | Recognized input names, framing and multiword/binary argument reconstruction within each check's source scope | Live backend acceptance, transaction delivery or migration recovery |
| Managed ownership, blocking, Pub/Sub and replication contracts | Explicit dispatch, deadline, drain and rejection rules in the implementation | Qualification of every combination of connection mode, topology and fault |
| Retained three-test persistent-string public lifecycle | Compatibility/governance/test/preflight flow, active Scan/BothRequired, gateway write ACK and independent source/target reads in a development fixture | Copy completion, all data types/commands, cutover/recovery, storage safety, sustained capacity or release certification |
| Two retained Redis 7.2.16 / Valkey 7.2.5 receipt checks | Short expiry, TTL-preserving restore, retry/collision handling and cleanup for their bounded cohort | Every foreground write, historical-copy expiry race, non-idempotent ordering or full failure matrix |
| TLS/credential and large-topology qualification material | Requirements and source mechanisms to exercise | A completed current-source live custom-CA/mTLS/rotation campaign or 120-pair scale acceptance |
| Request-path performance material | Measurement contract, evidence validation and baseline methodology | Current release throughput/latency/CPU clearance or a universal operations-per-core guarantee |
These retained checks have their own source/environment boundaries and are not a newly executed qualification of this documentation patch. No complete current-image fault/soak/cutover qualification or 120-pair production acceptance is established by the records reviewed here. A source review, a test count, a running job, or a brief string round trip cannot substitute for that evidence. Do not use synthetic topology sizes or offered load as measured capacity.
Qualify your migration
Record the exact Eden and backend image digests, source revisions, server versions/modules, TLS/ACL configuration, topology, client RESP version, command mix, key-size/type/TTL distribution, pipeline depth, CPU quota and network placement. Keep the compatibility result, explicit dispositions, test-run results, execution preflight and cutover preflight together with the run IDs.
Verify independently that acknowledged values reach the required backends, expiry is preserved within a declared tolerance, expired keys stay absent, non-idempotent effects keep order, and reads follow the selected authority. Exercise disconnects, saturation, credential rotation, node loss, process restart, durable storage failure and cleanup only in an isolated qualification environment. Retain unknown outcomes as unknown; never retry them merely to make a comparison pass.
Measure client latency/errors and actual completed work throughout historical copy and live traffic. A Running phase or SCAN activity alone is not sink progress. Use sink-confirmed durable progress and copy/replay watermarks. Before cutover, validate source/target equality under the chosen observation boundary. After target-authoritative traffic begins, target-only successful writes can make raw DBSIZE equality inappropriate; reconcile expected keys and TTLs as well as counts.
Failure and cutover
Before durable cutover, source responses remain authoritative. Source success with target rejection, or incomplete delivery evidence, can trigger sticky quarantine and source failback. Preserve that evidence and block completion. Process restart can add operation_restart_required; clearing a lease or restarting again does not reconcile the target.
Use recovery runbooks for stalled/quarantined operations. Complete only when durable preflight gates, application checks and operator acceptance pass. Keep the source until the agreed rollback/retention boundary; after committed cutover, reversal needs a separate validated compensating operation.