BetterDB Migrate vs RedisShake, RIOT and native replication
RedisShake is the tool most Redis to Valkey migrations end up using, and BetterDB uses it too: the migration workflow inside BetterDB Monitor runs RedisShake for its PSYNC and scan modes and adds a command-replay mode of its own. What BetterDB adds is everything around the copy: a read-only analysis that has to pass before execution is allowed, the right mode for what your source permits, a cutover screen that waits for every shard to catch up, a validation pass that compares sampled keys by type and value, and both databases monitored throughout. Execution runs on a BetterDB you host with a direct path to both databases; BetterDB Cloud runs the analysis only.
BetterDB Migrate is the migration workflow inside BetterDB Monitor, the same container: analyze, execute and validate a move between Redis and Valkey from the UI, with both databases monitored throughout.
Which path fits?
Run RedisShake yourself when…
- You are comfortable writing the config and running the binary
- You need its filters or Lua functions to reshape data in flight
- You need to read from RDB or AOF files
- You want one binary and nothing else
Use native replication or your cloud's path when…
- The source is Redis 7.2 or older and allows REPLICAOF - Valkey can replicate from it directly
- You are on node-based ElastiCache and only want to switch engine: the in-place upgrade keeps the endpoint
Use BetterDB Migrate when…
- You want to know what will break before you start - the analysis runs first and blocks execution on real incompatibilities
- The source blocks PSYNC and you need to know which fallback applies and what it costs in downtime
- You want a cutover screen with per-shard lag, and a validation report afterwards
- You want both sides monitored before, during and after, in the same tool
BetterDB Migrate and RedisShake
| Capability | BetterDB | RedisShake on its own |
|---|---|---|
| What it is | A three-phase workflow in BetterDB Monitor: analyze, execute, validate | A command-line data sync tool |
| Copy engine | RedisShake for the PSYNC and scan modes, plus its own command-replay mode | RedisShake |
| Pre-migration analysis | Samples 1,000 to 50,000 keys, estimates memory, and checks topology, modules, hash-field expiry, multiple databases, eviction policy, ACL users and functions. Execution refuses to start without a passing analysis less than 24 hours old | Not included. The README points to a separate compatibility tool |
| Redis to Valkey | PSYNC sync or command replay. The scan mode is refused across engines because DUMP payloads from Redis 7.4+ do not RESTORE on Valkey | Sync reader, or scan reader within the same engine; you find out at RESTORE time otherwise |
| Live writes during the copy | Sync mode: yes, until a brief pause at cutover. Scan and command modes: no - keys written after the scan starts are missed, so you quiesce the source first | Same: sync reader yes; scan reader needs quiesced writes, with optional catch-up from keyspace notifications |
| Cutover | Sync mode only: a screen with per-shard lag that waits until the target has stayed fully synced, then drains RedisShake. You pause writes and repoint clients yourself | Manual: watch the status port, then stop the process |
| Validation | DBSIZE on both sides, 500 sampled keys compared by type and value (large collections by element count), stream groups and last-delivered IDs, and an optional before/after baseline of ops, memory, fragmentation and CPU. Passes at zero issues and under 1% key-count difference | Not included. The docs suggest comparing key counts |
| Managed sources and targets | ElastiCache node-based and Serverless, MemoryDB, Redis Cloud and Upstash, with the mode each one allows (table below) | Any endpoint the reader can reach; restrictions are yours to discover |
| Topology | Standalone to standalone, standalone to cluster (keys resharded), cluster to cluster. Cluster to standalone is blocked | Standalone and cluster on either side |
| TLS | TLS on both sides. Client certificates (mTLS) in command mode only | TLS on both sides |
| Filters and transforms | No | Filter by key, database, command or slot; transform with Lua functions |
| Resume after an interruption | No. Keys already written stay on the target; start again | No |
| Topology change during the run | Not detected: a shard added or resharded mid-run is not replicated. Restart after the change | The process stops |
| ACLs and modules | Not migrated. The analysis reports missing ACL users as a warning and a missing module as blocking | Redis Stack modules are not supported |
| Monitoring during cutover | Source and target in the same tool: ops/sec, memory, clients, slowlog, anomalies | Not included |
What it is
BetterDB
A three-phase workflow in BetterDB Monitor: analyze, execute, validate
RedisShake on its own
A command-line data sync tool
Copy engine
BetterDB
RedisShake for the PSYNC and scan modes, plus its own command-replay mode
RedisShake on its own
RedisShake
Pre-migration analysis
BetterDB
Samples 1,000 to 50,000 keys, estimates memory, and checks topology, modules, hash-field expiry, multiple databases, eviction policy, ACL users and functions. Execution refuses to start without a passing analysis less than 24 hours old
RedisShake on its own
Not included. The README points to a separate compatibility tool
Redis to Valkey
BetterDB
PSYNC sync or command replay. The scan mode is refused across engines because DUMP payloads from Redis 7.4+ do not RESTORE on Valkey
RedisShake on its own
Sync reader, or scan reader within the same engine; you find out at RESTORE time otherwise
Live writes during the copy
BetterDB
Sync mode: yes, until a brief pause at cutover. Scan and command modes: no - keys written after the scan starts are missed, so you quiesce the source first
RedisShake on its own
Same: sync reader yes; scan reader needs quiesced writes, with optional catch-up from keyspace notifications
Cutover
BetterDB
Sync mode only: a screen with per-shard lag that waits until the target has stayed fully synced, then drains RedisShake. You pause writes and repoint clients yourself
RedisShake on its own
Manual: watch the status port, then stop the process
Validation
BetterDB
DBSIZE on both sides, 500 sampled keys compared by type and value (large collections by element count), stream groups and last-delivered IDs, and an optional before/after baseline of ops, memory, fragmentation and CPU. Passes at zero issues and under 1% key-count difference
RedisShake on its own
Not included. The docs suggest comparing key counts
Managed sources and targets
BetterDB
ElastiCache node-based and Serverless, MemoryDB, Redis Cloud and Upstash, with the mode each one allows (table below)
RedisShake on its own
Any endpoint the reader can reach; restrictions are yours to discover
Topology
BetterDB
Standalone to standalone, standalone to cluster (keys resharded), cluster to cluster. Cluster to standalone is blocked
RedisShake on its own
Standalone and cluster on either side
TLS
BetterDB
TLS on both sides. Client certificates (mTLS) in command mode only
RedisShake on its own
TLS on both sides
Filters and transforms
BetterDB
No
RedisShake on its own
Filter by key, database, command or slot; transform with Lua functions
Resume after an interruption
BetterDB
No. Keys already written stay on the target; start again
RedisShake on its own
No
Topology change during the run
BetterDB
Not detected: a shard added or resharded mid-run is not replicated. Restart after the change
RedisShake on its own
The process stops
ACLs and modules
BetterDB
Not migrated. The analysis reports missing ACL users as a warning and a missing module as blocking
RedisShake on its own
Redis Stack modules are not supported
Monitoring during cutover
BetterDB
Source and target in the same tool: ops/sec, memory, clients, slowlog, anomalies
RedisShake on its own
Not included
Checked against RedisShake v4.7.0, RIOT v4.3.0, the Valkey migration documentation and BetterDB 0.54.0, November 2026. Spot something out of date? Tell us and we will fix it.
Sources: RedisShake · RIOT · RIOT-X · Valkey migration guide · ElastiCache cross-engine upgrade · ElastiCache migration to Serverless · BetterDB migration docs
Which mode your source allows
The mode decides whether writes can continue. PSYNC sync keeps the source live; scan and command replay need writes paused for the whole copy.
Self-hosted Redis 7.2 or older, to Valkey
Modes available
PSYNC sync, or command replay
Writes during the copy
Live with sync; paused with command replay
Self-hosted Redis 7.4 or 8.x, to Valkey
Modes available
PSYNC sync, or command replay. Scan mode is refused: RDB v12 payloads do not RESTORE on Valkey
Writes during the copy
Live with sync; paused with command replay
Valkey to Valkey, or Redis to Redis
Modes available
PSYNC sync, scan, or command replay
Writes during the copy
Live with sync; paused otherwise
ElastiCache node-based (source)
Modes available
Scan to the same engine, or command replay. AWS blocks PSYNC
Writes during the copy
Paused for the copy
ElastiCache Serverless (source)
Modes available
Command replay only. PSYNC and MEMORY USAGE are blocked
Writes during the copy
Paused for the copy
ElastiCache as the target
Modes available
Node-based: all three modes. Serverless: PSYNC sync or command replay, TLS required
Writes during the copy
Depends on the source
KeyDB (source)
Modes available
PSYNC sync, or command replay
Writes during the copy
Live with sync; untested
Dragonfly (source)
Modes available
Command replay only; it does not serve PSYNC
Writes during the copy
Paused; untested
- MemoryDB, Redis Cloud and Upstash are supported as source or target; which modes each allows depends on whether the service permits PSYNC, which the analysis tells you.
- No throughput figures are published. Sync mode forks the source for the RDB; prefer a replica as the source where you have one. Scan and command modes read in batches of 500 keys with 50 in flight, and walk collections over 10,000 elements with HSCAN, SSCAN and ZSCAN.
What BetterDB adds around the copy
RedisShake moves the data. These are the steps before, during and after that otherwise live in a runbook.
An analysis that gates execution
Read-only. It samples keys, estimates memory, and checks topology, modules, hash-field expiry, multiple databases, eviction policy, ACL users and functions. Blocking findings stop execution unless you override with a reason, and an analysis older than 24 hours has to be re-run.
Example
BLOCKING module ReJSON loaded on source, missing on target WARNING 3 ACL users on source are not on target (not migrated) INFO source allows PSYNC -> sync mode available
A cutover you can watch
In sync mode the screen moves through initial sync, replicating and fully synced with per-shard lag. Cutover waits until the target has stayed fully synced for two seconds, within a timeout you set (300 seconds by default), then gives RedisShake 60 seconds to drain. A forced cutover records the lag you accepted.
Example
shard 0 lag 0 B fully synced shard 1 lag 0 B fully synced shard 2 lag 1.2 KiB replicating Initial sync complete. Pause writes on the source, then click Complete cutover
Validation after the move
Key counts summed across masters on both sides, 500 sampled keys compared by type and value, stream consumer groups checked by name and last-delivered ID, and an optional baseline that compares ops/sec, memory, fragmentation and CPU before and after. Pass means zero issues and under 1% key-count difference.
Example
keys source 1,204,331 target 1,203,988 (0.03%) sample 500 mismatches 0 baseline ops/sec +4% memory +2% fragmentation 1.21 -> normal
What BetterDB does not do
A migration tool is only useful if you know its limits before you plan around it. These are the ones that matter:
A run cannot resume after a restart; keys already written stay on the target and you start again. The scan and command modes are one-shot, so keys written during the run are missed - use sync mode if the source keeps taking writes. The RedisShake modes refuse to write over existing keys: the target has to be empty, or you choose the option that flushes every target master first. Command mode copies strings, hashes, lists, sets, sorted sets and streams and overwrites in place; other types are skipped and logged.
Per-field hash expiry is not transferred in command mode, only the key-level TTL. Command mode and cluster targets handle database 0 only. ACLs and modules are not copied. A shard added mid-run is not picked up. And BetterDB does not pause writes or redirect clients: at cutover you pause the source and repoint the application yourself. Nothing is ever written to the source, so rolling back is repointing clients to it.
Execution and validation need a direct network path to both databases from a BetterDB you host. Connections that go through the BetterDB agent or an SSH tunnel get the analysis only, and BetterDB Cloud does not execute migrations.
Start with the analysis
The analysis phase is read-only and runs from BetterDB Cloud or a self-hosted BetterDB. It tells you which mode your source supports and what would block the move, before anything is copied.
Other comparisons: redis_exporter · Prometheus and Grafana · OTel Redis receiver · Datadog · APM tools · Percona PMM · Valkey Admin · Redis Insight · CloudWatch · cloud monitoring · ElastiCache migration
FAQ
Can Valkey replicate directly from Redis?
From Redis 7.2 and older, yes: point a Valkey 7.2 or later replica at the Redis primary with REPLICAOF. From Redis 7.4 and later, no. The Valkey migration documentation states that RDB files produced by Redis CE 7.4 and later are not compatible, so those versions need a tool that copies data with commands instead of data files. That is also why BetterDB refuses its scan mode across engines and offers PSYNC sync or command replay instead.
Is RIOT still maintained?
No. The RIOT repository is archived and its description reads unmaintained, with a pointer to RIOT-X. RIOT-X limits production use to Redis products.
Does RedisShake support Valkey?
Yes. Its README lists Redis 2.8 through 8.4 and Valkey 8.x through 9.x.
Does BetterDB Migrate use RedisShake?
Yes, for two of its three modes. The sync mode runs the RedisShake PSYNC reader for continuous replication until cutover, and the scan mode runs its scan reader for a one-shot copy within the same engine. The third mode copies keys with ordinary type-specific commands - SET with PX, HSET, RPUSH, SADD, ZADD, XADD with consumer groups - for sources where neither of the others works.
What happens if a run fails halfway?
Nothing is rolled back: keys already written stay on the target, and the source is never modified. In command mode each compound key is written to a temporary key and renamed, so no single key is left half-copied. You fix the cause and start again; the RedisShake modes will refuse to overwrite the keys already there unless you flush the target first, and the UI offers that as a retry option.
Can I migrate from ElastiCache with BetterDB?
Yes, with the modes the service allows. AWS blocks PSYNC on every ElastiCache cache, so a node-based source gets scan mode to the same engine or command replay, and a Serverless source gets command replay only. Both need writes paused for the copy. The analysis tells you which applies before you start.
Are TTLs, streams and hash-field expiry preserved?
Key-level TTLs are preserved in every mode; in command mode strings are written atomically with SET PX and compound keys get PEXPIRE after a rename. Streams keep their consumer groups, consumers and pending entries. Per-field hash expiry is not carried by command replay, which keeps only the key-level TTL, and the analysis flags it when the target cannot hold it. Validation compares type and value, not TTL.
Deciding between more tools? When should you use BetterDB? →
Migration runs inside BetterDB Monitor - start it in one command
docker run -d -p 3001:3001 betterdb/monitor:latest
Then open http://localhost:3001 - see the Docker guide.
Ready to migrate?
Run the read-only analysis first, replicate with writes still live where the source allows it, and validate the target after cutover. Execution runs on a self-hosted BetterDB with Docker or npx.