We almost spent £180/month on Redis. We spent £40 instead.

by Rashed

We had a number in our heads: managed Redis, smallest HA tier, maybe $70 a month. We needed a Redis-class store for coordination primitives — JWT denylist, rate-limit counters, idempotency keys, distributed locks — and it had to survive a node dying, because some of those primitives sit on the money path. So we went to provision it.

The console had a different number. Memorystore for Redis Standard — the tier that actually gives you a high-availability replica — starts at 5GB. Not 1GB. The smallest HA config you can buy is $234/mo. We needed about 1.25GB. We were looking at paying 4.5× for capacity we'd never touch, purely to get the replica.

That gap between the number in our heads and the number on the screen is the whole story. We ended up on Memorystore for Valkey at $51/mo, with HA, and the migration cost us zero lines of code. Here's how we got there.

What the store is actually for

None of this matters unless the store earns its keep, so: what runs on it.

Four things, all of them coordination rather than data-of-record:

• Idempotency keys. Money-path endpoints (orders, payments, refunds, captures) dedupe retries against keys held here. If TanStack Query retries a payment POST on a network blip, the second request finds the key and replays the first response instead of charging twice.
• JWT denylist. Revoked tokens get checked against this on the way in.
• Rate limiting. Per-business counters.
• Locks. Short-lived coordination for workers that mustn't double-act.

Three of those four are either security or money. That's why "no HA" was never really on the table for go-live — if the store vanishes mid-incident, the idempotency guarantee vanishes with it, and the failure mode is a double charge, not a slow page. We do fail open on lookups to stay available, bounded by the access-token lifetime, but the store being up is the thing we're paying for.

So we needed HA. That's the constraint that made the pricing matter.

The number we had wrong

Here's the thing worth saying plainly, because it's the actual lesson: we quoted the price from memory and the memory was wrong.

We'd assumed Memorystore for Redis "Standard 1GB" was a thing that existed at roughly $70/mo. It isn't. On GCP, the Redis Basic tier gives you 1GB but no replica — no HA at all. The moment you want a standby replica, you're on Standard, and Standard has a 5GB floor. There is no 1GB HA Redis. The cheapest HA Redis you can provision is 5GB at $234/mo.

We only found this by opening the console for our actual region (europe-west2) and trying to build the thing. Every back-of-envelope number we'd written in the planning doc was wrong, because we'd been pricing a configuration that doesn't exist.

These are the numbers we actually saw, verified in the console on the day we provisioned:

The shape of the table is the argument. Redis Basic is cheap but gives us nothing we can launch payments on. Redis Standard gives us HA but bundles it with 4GB of RAM we will never address. Valkey gives us HA at a size that matches the workload.

Why Valkey, specifically

Valkey is the open-source fork of Redis that the Linux Foundation picked up after Redis changed its license in 2024. On GCP it shows up as Memorystore for Valkey, and the reason it was an easy call comes down to four things.

The migration was free. Valkey is wire-compatible with Redis 7.2. Our client is ioredis, and ioredis does not know or care whether it's talking to Redis or Valkey — same protocol, same commands, same connection code. We changed the host it points at. That was the entire code change. There's a version of this post where switching datastores is a two-week migration; this was not that.

The license is actually open. Valkey is BSD-3-licensed. Redis moved to a source-available license (RSALv2 / SSPLv1). For us this is a portability question, not an ideology one: if we ever leave GCP, an open-source-licensed store is one fewer thing tying us to a vendor's managed offering. It costs nothing today and buys optionality later.

The networking is the modern path. Memorystore for Valkey connects over Private Service Connect into the platform VPC, rather than the older VPC-peering model. PSC doesn't consume an IP range from our network and gives finer-grained access control. It's a one-time service-connection setup, about fifteen minutes, documented in our runbook. We'd rather be on the path Google is investing in than the one they're winding down.

HA at a sane size. This is the one that started the whole thing. Valkey lets us provision a small instance (a ~1.25GB pico) and separately choose to add a replica. The HA decision is decoupled from the capacity decision. With Redis Standard those two are welded together at 5GB.

The pre-launch trick

One detail that saved us money without costing us anything: the replica is a toggle, so we don't pay for it before we need it.

In the test phase, where there are no real payments and a node dying means a developer reruns something, we run Valkey with zero replicas at about $26/mo. The day before we start processing live payments, we bump it to one replica and it becomes $51/mo HA. Same instance, same data model, same connection string — one setting.

We're not paying for a standby to protect test traffic that doesn't need protecting. The HA cost lands exactly when the thing it protects goes live, and not a month earlier.

What we picked, what we rejected, why

We picked Memorystore for Valkey, pico size, one replica, europe-west2, over Private Service Connect — $51/mo, HA, wire-compatible with our existing Redis client.

We rejected Redis Basic 1GB ($39/mo). It's the cheapest line on the table and it was never viable, because it has no replica. Saving $12/mo to run our idempotency and denylist on a single node with no failover is a false economy the first time that node restarts during a payment.

We rejected Redis Standard 5GB ($234/mo). This is the option we'd have sleepwalked into if we hadn't opened the console. It's a perfectly good product; it's just sized for a workload four and a half times ours, and you can't buy it smaller. Paying $183/mo more than Valkey for 4GB of RAM we'll never address is the definition of overprovisioning.

What we gave up by choosing Valkey: Redis is the older, more battle-tested managed product with a deeper operational track record on GCP. Valkey-on-Memorystore is newer. We're betting that wire-compatibility plus an open license plus a managed SLA covers the maturity gap for a coordination store — and that bet is much easier to make when the thing speaks the exact same protocol, so reverting would also be a one-line change.

The takeaway

The lesson isn't "use Valkey." The lesson is the thing that nearly cost us $183 a month: don't quote cloud pricing from memory — open the console for your actual region and try to build the actual thing. Our planning number was off by a factor that mattered, not because we were careless but because the tier we assumed existed simply doesn't. Pricing pages have floors, minimums, and tier boundaries that don't show up until you're in the provisioning flow.

Two questions worth asking before you provision any managed datastore. First: do you actually need HA, or are you about to pay for a replica to protect traffic that can tolerate a restart? For us the answer was yes, but only on the money path, and only at go-live. Second: is your capacity floor set by your workload or by the vendor's smallest HA tier? If it's the vendor's, there's usually a wire-compatible alternative that lets you size HA and capacity independently.

We'll come back to the things this store actually powers in later posts — the idempotency middleware on the money paths is its own story, and so is the JWT denylist. This one was about the bill. We almost paid £180 a month. We pay £40.