BetterDB – open-source Redis/Valkey migration across clouds and self-hosted
I built this after a year at Redis as an engineering manager for their developer tools, watching the ecosystem fragment after the license change.
Redis 7.4 broke data file compatibility with Valkey. RIOT, the only widely-used open migration tool, was archived last October with no open replacement. And the clouds - AWS, GCP, Redis Cloud - have no incentive to make leaving easy. If you want to move between providers, switch protocols, or get off managed infrastructure entirely, you're on your own.
BetterDB ships a three-phase workflow to fix that:
Analysis - scans your keyspace and flags blocking incompatibilities before anything moves. Green/amber/red verdict.
Execution - RedisShake for same-protocol speed, or command-based for cross-version and cross-protocol migrations where binary transfer fails.
Validation - key count comparison, sample spot-check, and performance baseline comparison against pre-migration snapshots.
Any direction. Any provider. Standalone or cluster.
docker run -p 3000:3000 betterdb/monitor
Website: https://betterdb.com Repo: https://github.com/BetterDB-inc/monitor Docs: https://docs.betterdb.com
The most useful Redis pattern I've found for real-time data: write with explicit TTLs and let stale data expire naturally instead of invalidating. If your writer dies, the data expires on its own within the TTL window. No stale data served indefinitely. Simple but surprisingly hard to break
The simplest approach is the best in 90%+ of the cases!
Show HN projects that solve one specific workflow problem tend to outlast the ambitious all-in-one tools. Scope is a feature.
That's exactly the bet we're making. The Redis/Valkey ecosystem has enough sprawl - a tool that does one thing well and stays out of the way is what we'd want to use ourselves.
Exciting! Good luck!
Thank you!
This seems to be the hardest part with migration tools. The more they try to be "universal" (compatible with different providers, protocols, and configurations), the more edge cases they have to handle, and that's where problems usually arise. Having a clear scope and an explicit indication of "this won't work here" is often more helpful than trying to support everything.