BetterDB vs ElastiCache Serverless migration
AWS now migrates self-managed Valkey and Redis clusters on EC2 into ElastiCache Serverless with a proxy that flips the cutover for you. It goes one direction, from one kind of source, into one product.
BetterDB goes between Redis and Valkey in either direction, takes KeyDB and Dragonfly along in the modes they support, and tells you what you are moving before and after.
Same replication protocol, different scope
| Need | BetterDB | ElastiCache Serverless migration |
|---|---|---|
| Replication mechanism | PSYNC per shard via RedisShake, or key-by-key command mode | PSYNC per shard via managed migration nodes |
| Supported sources | Any reachable Redis or Valkey: self-hosted, ElastiCache, MemoryDB, Redis Cloud, Upstash, other clouds. Other RESP-compatible engines such as KeyDB and Dragonfly in the modes they support (Dragonfly does not serve PSYNC, so command mode) | Self-managed cluster-mode Valkey 7.2 to 8.1 or Redis OSS 4.0 to 7.2 on EC2 |
| ElastiCache node-based or MemoryDB as a source | Yes, in DUMP/RESTORE or command mode, with BetterDB Monitor running inside the VPC (AWS blocks PSYNC on its caches) | Not supported |
| Standalone (non-cluster) sources | Yes, to standalone or cluster targets | Not supported |
| Supported targets | Any Redis or Valkey, standalone or cluster (a cluster source needs a cluster target); KeyDB and Dragonfly in sync or command mode | An empty ElastiCache Serverless for Valkey cache on the same or higher version |
| Migrating out of ElastiCache Serverless | Command mode (AWS blocks PSYNC, so no continuous sync from a Serverless source) | Serverless is not supported as a source |
| Cross-engine (Redis to Valkey, Valkey to Redis, KeyDB or Dragonfly to either) | Redis and Valkey in either direction, with function-library filtering; KeyDB and Dragonfly via command mode | Redis OSS to Valkey only |
| Application traffic during sync | Unchanged, straight to the source | Routed through the migration endpoint proxy to the source |
| Cutover | Operator pauses writes, waits for lag to drain, repoints the application | Proxy flips per shard at the next fully synced window, manual or automatic |
| Pipelining during migration | Unaffected | Serialised: each pipelined command becomes a round trip |
| Pre-migration analysis | Key sampling, memory estimate, TTL distribution, HFE, modules, ACL, multi-db and eviction-policy checks with a blocking gate | Prerequisite checks at prepare time |
| Post-migration validation | Key count across every master plus sample value comparison | None |
| Rollback after cutover | Repoint the application back; the source was never modified | None; returning to the source is a manual repoint |
| Recovery after an error | Fix the cause and run again | Errors are permanent; the migration can only be force-completed |
| Cost | Analysis in the free MIT core; execution and validation in Pro | Free for 180 days per account, then per node-hour while the migration exists |
AWS details are taken from the ElastiCache Serverless online migration documentation as of October 2026. Both tools replicate with PSYNC; the differences are in what they accept, what sits in the data path, and what happens around the copy.
Proxy cutover vs operator cutover
We wrote up how the two designs handle the moment the application has to switch: what a proxy in the path buys, what it costs in pipelining and rollback, and what an operator-driven cutover needs to make the same decision from the screen instead of a log line.
Read the design comparison →FAQ
Can BetterDB migrate into ElastiCache Serverless?
Yes. ElastiCache Serverless is a supported target, and both RedisShake sync mode and command mode write to it over TLS. Migration execution connects to the cache directly rather than through the BetterDB agent, so run the self-hosted BetterDB Monitor on a host inside the VPC, such as an EC2 instance. The source can be anywhere that host can reach: self-hosted, node-based ElastiCache, MemoryDB, another cloud, or a different engine such as KeyDB or Dragonfly (Dragonfly in command mode, since it does not serve PSYNC).
Can BetterDB migrate out of ElastiCache?
Yes, as a snapshot copy. AWS restricts PSYNC and SYNC on every ElastiCache cache, node-based and Serverless alike, so nothing can attach to one as a replica and the continuous sync mode does not apply. Command mode reads each key with type-specific commands and writes it to the target with its TTL preserved; DUMP/RESTORE mode works from node-based caches when the RDB versions match. Quiesce writes on the source for a consistent copy.
Which should I use if I am moving a self-managed cluster on EC2 into Serverless?
If your source is cluster mode, your client does not depend on pipelining, and you do not need a validation step or a rollback path, the AWS tool is the simpler option because the proxy handles the cutover for you. Use BetterDB when any of those is false, when the source is standalone or managed, or when you want a compatibility report before you commit and a verification after.
Does BetterDB offer zero-downtime migration?
BetterDB offers near-zero downtime. Sync mode replicates continuously and the cutover is a short write pause that you schedule. AWS defines zero downtime as zero client errors, which its proxy achieves at the cost of serialised pipelines and closed connections for in-flight writes. Without a proxy in the path, the write pause is yours to run, and it is typically seconds.
Can I use BetterDB to monitor an AWS-run migration?
Yes, and it fills a gap AWS documents: there are no migration-specific metrics and no way to poll migration health on demand. The AWS migration nodes attach to your source as replicas, so BetterDB shows their replication offsets and lag, the CPU and memory headroom the prerequisites require on the source primaries, and any client still writing directly to the source. That last one matters because a direct write of a command Serverless does not support is not replicated, and AWS reports it as a permanent migration error.
Planning a move? How BetterDB migration works →
Ready to get started?
Start monitoring in minutes - no infrastructure to maintain. Team collaboration, agent-based monitoring for private databases, and more. Or self-host - open source core, zero lock-in.