Valkey replaces Redis for cloud cost optimization

The engine divergence

The community forked Redis 7.2.4 into Valkey in March 2024 because Redis Ltd switched to the SSPL and RSAL licenses, which necessitated a move to the Linux Foundation to maintain a permissive BSD-3 license for all users. This transition followed Redis Labs’ decision to require commercial agreements for managed services. Valkey 9.1 improved memory efficiency by cutting per-key overhead by 44% for strings and 8.5 bytes per sorted set member. While Redis 8.6 offers 5x throughput over 7.2, Valkey remains 90% compatible at the command level. I find the divergence between the two projects grows as Redis focuses on native AI features like semantic caching and vector search. Valkey 9.0 added support for multiple logical databases in cluster mode and atomic slot migration. The project now has 150 contributors from 40 organizations. Valkey demonstrated over one billion requests per second on a 2,000-node cluster. Amazon ElastiCache for Valkey now supports both caching and persistent workloads, offering synchronous or asynchronous durability to manage data loss risks. The projects have diverged enough that they are no longer the same software, though they share the same RESP protocol.

Cost and performance

Cost management requires choosing the right engine for your workload. I see a massive difference in price when comparing Redis OSS to Valkey on Amazon ElastiCache. For a developer running small, near-empty caches, the Redis OSS 1 GB minimum storage floor makes it an expensive mistake. Valkey uses a 100 MB minimum floor, which reduces monthly costs for small datasets by 15x.

Dragonfly outperforms Valkey on GCP for high-concurrency tasks. Dragonfly achieves 4.5x more throughput on 48 vCPUs because its architecture uses multiple threads to handle data shards, whereas Valkey remains limited by a single main thread. Dragonfly also used 38% less memory per item than Valkey in specific tests. I must note that Valkey’s performance in batched requests leads Dragonfly, but the single-threaded bottleneck remains. If you require a database that scales linearly with CPUs, Dragonfly is the better choice. For an application with 100,000 requests per second and a 100 GB peak, ElastiCache for Valkey costs $2.919 per hour, while an on-demand node cluster for the same workload costs $5.6552 per hour. For highly variable or spiky traffic, Upstash offers a pay-per-command model that scales to zero, whereas ElastiCache remains an always-on infrastructure.

Migration and verdict

I recommend switching all dev and staging workloads to Valkey Serverless to capture an immediate 33% reduction in ECPU and storage costs. If you are already using Redis for heavy module-based work, you might face a difficult rewrite. For instance, Redis 8.4 added hybrid search that Valkey cannot match. I ran a migration to Valkey 8.x and hit a wall with ioredis due to how the library handled version negotiation during connection setup using CLIENT INFO and HELLO commands. You must audit your client library compatibility before you attempt to migrate. Will the community ever build a mature equivalent for RedisSearch? For standard caching, rate limiting, and session storage, Valkey is the winner. If you need advanced features like time series or probabilistic structures, stick with Redis. The primary node tracks the age of the oldest unpersisted write and publishes it to Amazon CloudWatch as the DurabilityLag metric. You should check your client library compatibility before you attempt to migrate.