Okay, so I held off on writing this for almost a year because I assumed the dust would settle. It mostly hasn’t. Valkey shipped, AWS shipped it, every major Linux distro now packages it as the default key-value store, and people keep asking me the same question on Twitter: did you actually switch?<\/p>\n
Short answer: half of my production caches now run Valkey, half still run Redis. The cutover wasn’t a manifesto. It was three pull requests, a few Terraform diffs, and two weekends of checking that nothing broke. Nothing broke.<\/p>\n
This post is the boring version of what happened. Not the license drama, not the Reddit threads, just the parts that actually affect what you deploy. I’ll tell you which workloads I moved, which I kept on Redis, and why the choice isn’t as obvious as either side claims.<\/p>\n
I had to keep reminding myself of this: Valkey forked from Redis 7.2.4 in March 2024 after Redis Inc. moved away from BSD-3 to a dual SSPL\/RSALv2 license. The Linux Foundation picked up the fork<\/a>, several of the most active core contributors went with it (including Madelyn Olson at AWS), and AWS, Google Cloud, Oracle, and a stack of others put real engineers on it.<\/p>\n In practice that means the wire protocol is identical. RESP2, RESP3, cluster mode, sentinel. All of it. My existing The differences are in licensing, governance, and now in roadmap. Valkey 8 added multi-threaded I\/O improvements<\/a> that Redis Inc. is also working on but shipped later. Redis 8.x has Vector Sets and a different vector-similarity story. Both are real. Neither is decisive for most workloads.<\/p>\n If you’re using Redis as a cache or a queue with BullMQ or Sidekiq, the move is genuinely uneventful.<\/p>\n The biggest case was a Next.js app I run that uses Redis for session storage and for caching API responses from a vendor. Hot path traffic, maybe 4k req\/s at peak, mostly GET \/ SET \/ EXPIRE.<\/p>\n I migrated this in February. The actual steps were:<\/p>\n Total downtime: zero. Total code change: one environment variable. The cost change was real and not marketing fluff. For this workload, my monthly bill dropped from about $214 to $145.<\/p>\n The interesting part wasn’t the savings. It was that nothing in our error budgets, latency graphs, or p99s moved. I keep a private dashboard for this kind of decision and the only delta was the line item on the AWS invoice.<\/p>\n The other half of my stack uses Redis Stack. Specifically RediSearch and RedisJSON. I have one service that does full-text and vector search over a few hundred thousand documents, and another that stores nested JSON state for a workflow engine.<\/p>\n Valkey 8 didn’t ship equivalents. There are forks like valkey-search<\/a> and valkey-json<\/a> but they aren’t at the same maturity level. The Redis Stack modules are battle-tested, the docs are good, and the licensing change doesn’t actually bite me if I’m just running them in EC2. The RSALv2\/SSPL terms<\/a> restrict cloud providers who want to resell Redis as a service, not most end-user companies running it as part of their own product.<\/p>\n So I kept Redis Stack on the two services that needed it. Plain key-value caches and queues are on Valkey.<\/p>\n The point is you can mix them. They speak the same protocol on the same network, and your application code doesn’t care.<\/p>\n I keep seeing benchmark posts comparing Valkey 8 and Redis 7.4 that have Valkey winning by 2 to 3x on ops\/sec. They’re real but the conditions matter. Valkey 8’s multi-threaded I\/O is a meaningful upgrade for high-connection workloads. If you have one Node.js process pulling 5k req\/s against a single Redis instance, you’ll see modest gains. If you have 200 connections from different services hammering the same instance, you’ll see big gains.<\/p>\n I ran a sloppy benchmark on my own gear before I committed:<\/p>\n That’s about 16% faster, not 200%. The benchmarks claiming massive gains usually run with hundreds of clients, which is where the I\/O threading pays off. Your workload probably looks more like mine than like the benchmark.<\/p>\n The Valkey performance writeup<\/a> is honest about this. Read it before you make claims in your stand-up.<\/p>\n Three things I cared about more than the license fight.<\/p>\n Client library support. All the major clients ( Observability. Same Hosted options. AWS ElastiCache for Valkey is GA and cheaper. Google Cloud has Memorystore for Valkey. Aiven has both. DigitalOcean Managed Databases offers both. If you’re self-hosting, the Docker images are equivalent in resource footprint.<\/p>\n The thing nobody tells you: ElastiCache for Redis 7.x and ElastiCache for Valkey 8.x are not the same SKU. You can’t just “upgrade.” You spin up a new cluster and migrate. That’s how I did it and it’s the only sane way.<\/p>\n If you’re using Redis as a cache or a queue and you don’t depend on Stack modules, go to Valkey. It’s cheaper on managed services, the performance is at least equivalent, the licensing is fully open source under BSD-3, and the migration is genuinely trivial.<\/p>\n If you depend on RediSearch, RedisJSON, RedisTimeSeries, or RedisBloom in production today, stay on Redis. The Valkey ecosystem will eventually fill those gaps, but I don’t bet production on “eventually.”<\/p>\n If you’re greenfield and you need search or vector capabilities, evaluate both Redis Stack and a separate purpose-built tool. Postgres can handle a lot more than people give it credit for, and I made that case in detail in my post on Postgres JSONB<\/a>.<\/p>\n The honest answer to “should I switch” is: pick the boring choice. For caches and queues, Valkey is the boring choice now. For everything else, you already know.<\/p>\nredis-cli<\/code> works against a Valkey 8 instance and so does the ioredis<\/code> client I had on a Node.js API I haven’t touched in two years. I didn’t change a single line of application code on the services I moved.<\/p>\n# Same client, same protocol, both servers respond\n$ redis-cli -h cache.prod.internal -p 6379 PING\nPONG\n$ redis-cli -h cache-vk.prod.internal -p 6379 PING\nPONG\n<\/code><\/pre>\nWhere I switched: caching layer for a Next.js app<\/h2>\n
\n
MIGRATE<\/code> command to copy a few keys for sanity. For the live cutover I dual-wrote for 48 hours and then switched the read endpoint.<\/li>\nWhere I stayed on Redis: the Stack features<\/h2>\n
# docker-compose snippet, Valkey for cache, Redis Stack for search\nservices:\n cache:\n image: valkey\/valkey:8.1-alpine\n ports: ["6379:6379"]\n command: valkey-server --save "" --appendonly no\n\n search:\n image: redis\/redis-stack-server:7.4.0-v0\n ports: ["6380:6379"]\n<\/code><\/pre>\nThe performance question, with actual numbers<\/h2>\n
# Single client, 50 parallel connections, GET-heavy\n$ redis-benchmark -h cache-redis -t get -n 1000000 -c 50 -q\nGET: 138217.51 requests per second\n\n$ redis-benchmark -h cache-valkey -t get -n 1000000 -c 50 -q\nGET: 161031.69 requests per second\n<\/code><\/pre>\nThe boring operational stuff that actually matters<\/h2>\n
node-redis<\/code>, ioredis<\/code>, redis-py<\/code>, go-redis<\/code>, jedis<\/code>, lettuce<\/code>) explicitly support Valkey because the protocol is the same. The official Valkey project is also building valkey-glide<\/a>, a multi-language client co-developed by AWS. It’s good. I haven’t switched off ioredis<\/code> because it works, but glide is a real option now.<\/p>\nINFO<\/code>, same MONITOR<\/code>, same SLOWLOG<\/code>. My Datadog dashboards didn’t need a single change. Prometheus exporters for both are interchangeable in my setup.<\/p>\nSo what do I actually recommend<\/h2>\n