Valkey vs Redis in 2026: Should You Migrate Your SaaS Off Redis?
The Valkey vs Redis question started as a licensing argument in 2024 and has quietly turned into an ordinary infrastructure decision. Redis relicensed away from BSD, a Linux Foundation fork appeared with backing from AWS, Google, Oracle, Ericsson, and Snap, and for about a year the discussion was mostly about principles. Two years on, both projects have shipped several major versions, Redis has added AGPLv3 back into its license options, and the managed offerings have diverged on price. The decision now rests on much duller ground: cost, feature fit, and how much operational risk a migration actually carries for your team.
Most teams we talk to are running Redis for three things: session storage, cache, and a job queue behind Symfony Messenger or BullMQ. For that workload the honest answer is that either engine works, and the deciding factor is rarely technical. This post lays out what changed, what did not, and a decision framework you can apply in an afternoon instead of a quarter.
What Actually Changed in the Redis License
In March 2024, Redis moved from the BSD 3-Clause license to a dual RSALv2 and SSPLv1 arrangement. The practical target of that change was cloud providers reselling Redis as a managed service. The Linux Foundation forked the last BSD-licensed release into Valkey within weeks, and the major cloud vendors moved their engineering effort there.
Then, in May 2025, Redis added AGPLv3 as a third license option starting with Redis 8. That matters, because AGPLv3 is an OSI-approved open source license, so the "Redis is no longer open source" framing stopped being accurate. What AGPLv3 does require is source disclosure for modified versions reachable over a network. If you run stock Redis as a cache behind your application, that obligation does not touch your application code. If you fork Redis, patch it, and expose the patched build as a network service, you owe those modifications to your users.
This is the single most misunderstood point in the Valkey vs Redis debate, so it is worth stating plainly: for a typical B2B SaaS running a managed Redis instance from AWS, Google Cloud, or a European hosting provider, and doing nothing more exotic than SET, GET, and a Lua script or two, the license change had no legal consequence. Nobody needs to migrate for compliance reasons. Teams that do have a real exposure are the ones embedding a cache engine into a product they distribute, building on top of a patched fork, or operating under a procurement policy that flatly rejects copyleft licenses in the dependency tree. That last case is more common in enterprise and public-sector deals than engineers expect, and it is a legitimate reason to prefer BSD.
Valkey vs Redis: Where Feature Parity Stands
Valkey started as a fork of Redis 7.2.4, so the core command set, data types, and client protocol are identical. Every mainstream client library speaks to both without modification. Since then the two projects have taken different paths.
Valkey put its early effort into throughput and replication. Version 8 introduced asynchronous I/O threading and dual-channel replication, which separates the RDB snapshot transfer from the ongoing replication stream and meaningfully shortens full-sync windows on large datasets. Version 9, released in 2025 and iterated through 2026, added atomic slot migration for cluster resharding and BSD-licensed equivalents for JSON, Bloom filters, and vector search delivered as modules rather than core features. Recent 9.x benchmarks put it in the low millions of requests per second on commodity hardware, modestly ahead of comparable Redis builds on cache-heavy workloads.
Redis went wide instead. Redis 8 folded the former Redis Stack modules into core: JSON, Time Series, probabilistic structures, and the Query Engine now ship in the standard distribution, along with Vector Sets as a first-class data type. Redis 8.2 landed in early 2026 with client-side caching protocol improvements and better vector similarity options. If you are using Redis as a search engine, a time series store, or a vector database, Redis is still ahead and the gap is real rather than cosmetic.
So the parity question resolves cleanly. If Redis is a cache, a session store, a rate limiter, a lock, or a queue backend for you, Valkey is a drop-in replacement and you will not notice the difference. If Redis is doing full-text search or time series work in your stack, Valkey does not yet cover you.
The Operational Risk of Migrating
A Valkey migration is not a database migration, and treating it like one is the most common source of overestimation. There is no schema, no ORM mapping, and in most cases no application code change. The client library stays the same. The connection string points somewhere new.
What you do need to plan for is the data itself. Redis persistence formats have diverged since the fork, so an RDB file written by Redis 8 is not guaranteed to load into Valkey 9. The reliable paths are replication-based cutover, where you attach Valkey as a replica of your existing Redis primary and promote it during a short maintenance window, or a cold start where you accept an empty cache and let it refill. For a pure cache, the cold start is usually fine and takes ten minutes of planning. For session storage, you either replicate or you log everyone out, and only one of those is acceptable on a Tuesday morning.
The other thing to check is anything module-shaped. RediSearch, RedisJSON, RedisTimeSeries, and RedisBloom have Valkey counterparts with overlapping but not identical APIs, and a naive swap will break query syntax. Grep your codebase for FT., JSON., and TS. commands before you promise anyone a two-hour migration. This is exactly the kind of thing a short code and dependency review surfaces in an hour and a rushed cutover discovers at 3 a.m.
Symfony and Next.js Configuration Notes
On the Symfony side, both predis/predis and the phpredis extension connect to Valkey without changes, because the wire protocol is the same. Cache and session configuration in framework.yaml needs only a new DSN, and Symfony Messenger's Redis transport works unchanged against Valkey. If you are running Redis Sentinel, note that Valkey's Sentinel equivalent is compatible but the binary names differ in some distributions, so your health checks and systemd units may need editing even though your application does not.
On the Next.js side, ioredis and node-redis both work, and BullMQ runs on Valkey in production for plenty of teams. The one place to look carefully is any code depending on a Redis 8 specific feature, particularly Vector Sets or the Query Engine, which have no direct Valkey equivalent. If your Next.js app uses Redis purely for ISR cache tags, rate limiting, or a session store, there is nothing to change beyond configuration.
Whichever direction you go, keep the engine choice behind a thin abstraction in your own code. Not because you plan to switch again, but because the teams that had a painless migration in 2026 were the ones who had not scattered raw client calls across forty files. That discipline is the same one that makes a legacy modernization project tractable years later.
The Cost Case, Which Is Usually the Real Case
Price is where the decision gets concrete. AWS has positioned ElastiCache for Valkey roughly 20 percent below Redis OSS on node-based pricing and closer to a third below it on serverless, and Database Savings Plans stack further discounts on top. Google Memorystore, Aiven, and Upstash all offer Valkey tiers with similar positioning. For a team spending 200 euros a month on cache, that is a rounding error. For a team spending 4,000 euros a month across several environments, it is a real line item that recurs forever.
That asymmetry drives a simple rule. The migration costs you a fixed amount of engineering time, somewhere between half a day and two weeks depending on how many modules you use and whether you need replication-based cutover. The savings recur monthly. Divide one by the other and you get a payback period. If it is under six months, migrate. If it is over two years, do not spend the meeting time.
A Decision Framework You Can Apply Today
Work through these in order and stop at the first clear answer.
Migrate to Valkey if any of these apply: your procurement or legal team has a policy against copyleft licenses in production dependencies, your managed cache bill is large enough that a 20 to 30 percent reduction has a payback period under a year, you are already on AWS and using ElastiCache where Valkey is now the recommended default engine, or you are standing up new infrastructure and have no migration cost at all. That last case is the easiest call in this entire post: for greenfield caching workloads, default to Valkey.
Stay on Redis if any of these apply: you depend on the Query Engine, Time Series, or Vector Sets, your cache spend is small enough that the savings do not justify the change window, your team has no capacity for infrastructure work this quarter, or you are running a Redis Enterprise contract with support terms you actually use.
Do nothing if neither list produces a clear answer. A cache engine you are not thinking about is a cache engine that is working, and "we could save 40 euros a month" is not a strategy. Revisit it when you next renegotiate hosting or replatform something adjacent.
Where Wolf-Tech Fits
We help SaaS teams make this kind of call without turning it into a quarter-long evaluation. In practice that usually means one session to map what your cache is actually doing, a look at whether any module dependencies would break, and a cutover plan sized to the risk rather than to the hype. Sometimes the recommendation is to migrate next sprint. More often it is to leave it alone and spend the week on something that moves the product, which is a perfectly good outcome for an infrastructure review.
If you are weighing this decision, or a larger tech stack strategy question sitting behind it, write to us at hello@wolf-tech.io or visit wolf-tech.io. We are happy to look at your setup and tell you plainly whether the migration is worth your team's time.