We run Amazon MemoryDB on Redis 7. In October, AWS added Valkey to both ElastiCache and MemoryDB, and at that point the shape of the road ahead became visible: Redis OSS on AWS tops out in the 7.x line, and 7.2 and above are Valkey. Whatever Redis ships next, it is not arriving on the service we are on.

That is not an outage and it is not a deadline this quarter. It is the sort of thing where you either look at it deliberately now, or you look at it in a hurry later. So we spent a week on it. The outcome was that we changed nothing, and I think the week was still worth it — this is what it bought.

What actually depends on it

Two things, and they were the whole evaluation.

The first is the socket layer. The platform pushes live updates to browsers, and the instances serving those sockets are behind a load balancer, so a message raised on one instance has to reach clients connected to another. That fan-out is Redis pub/sub. It is not caching — if it stops, the product visibly stops updating.

The second is BullMQ, which I have written about choosing. It is the queue behind Stripe webhook reconciliation, seat recalculations and invoice generation. What it relies on is not a general idea of Redis: it is blocking list operations, sorted sets for delayed and retried jobs, and a substantial amount of Lua running server-side to make its state transitions atomic.

Neither of these treats Redis as a cache you can lose. Both treat it as the thing that makes correctness work. That framing decided more of the week than any price did.

The three options

Stay on MemoryDB for Redis 7. Costs nothing today. Accepts that the version line is terminal and that the decision comes back later, on someone else's schedule rather than ours.

MemoryDB for Valkey. The forward path within the service we already use. Priced 30 per cent below MemoryDB for Redis OSS, and data written is not charged up to 10 TB a month, with anything above that at a rate well below the Redis equivalent. For a workload like ours, where the write volume is queue traffic and socket fan-out rather than bulk data, that second part matters more than the headline percentage.

Redis's own managed offering. Redis Enterprise Cloud runs on AWS and can be bought through the Marketplace on the consolidated bill, under the collaboration agreement the two companies have had since 2022. This is the option where you follow the software rather than the service — you stay with the people writing Redis, and you leave the AWS-native service behind.

What the week actually went on

Very little of it went on price. That surprised me, and in hindsight it should not have.

The saving from Valkey is real and it is a percentage of a bill that is not one of our larger ones. A 30 per cent reduction on a line item that is not near the top of the invoice is worth having and is not worth a risky migration on its own. Once that was established — and it took about a morning — price stopped being the deciding input and became a tie-breaker for a tie that never arrived.

Most of the week went on compatibility, and specifically on the Lua. Valkey at this point is Redis 7.2.4 with a different name, so on paper everything BullMQ does is supported. On paper is doing real work in that sentence. BullMQ's guarantees come from scripts that assume precise semantics for how commands behave under concurrency, and "the command exists" is a much weaker statement than "the command behaves identically under contention". Establishing the stronger one means running the queue under real load against the new engine and watching for the failure modes that only appear when two workers race, which is not a read-the-docs exercise.

The socket layer was easier to convince ourselves about — pub/sub is old, simple, and identical across both — but it is also the part where a subtle failure is most visible to customers, because it does not error, it just stops delivering.

And the Redis Cloud option came apart on operational grounds rather than technical ones. Moving there means leaving an AWS-native service, which means our own VPC and networking work, a different support relationship, a different monitoring story, and a vendor relationship somebody has to own. All of that is doable. None of it was justified by the problem we actually had.

Why we stayed

Because the thing forcing a decision was not urgent, and everything on offer was a change to the datastore underneath a queue and a live socket fan-out.

The honest version is that we would be taking real risk — the kind that surfaces under production concurrency, weeks after a migration, in code whose correctness depends on server-side script semantics — in exchange for a percentage of a moderate bill and the feeling of being ahead of a deprecation that has not been scheduled against us yet.

That is not a good trade, and recognising it is not the same as ignoring the problem.

What the week actually produced

No migration, and three things I would not have had otherwise.

We know what we depend on. There is now a written list of exactly which Redis behaviours the platform relies on, feature by feature, and where each one is used. That list is the input to this decision whenever it comes back, and it took a day to make.

We know what the migration looks like. Not a guess — the actual sequence, including the part nobody enjoys, which is proving the queue's script semantics under load rather than assuming them. When there is a reason to do it, we are not starting from a blank page.

And we know what would change our minds. A security fix we cannot get, a client library dropping support for the version we are on, or a published end-of-support date with a quarter attached to it. Those are the triggers, they are written down, and somebody will notice them.

A week to decide to do nothing sounds like a week wasted. It is the difference between having decided not to migrate and merely not having migrated, and those two things look identical right up until the moment they do not.