Redis Pricing Pitfalls: How We Saved £140/Month with Valkey

Cloud database pricing often presents a dilemma: the tier that provides essential features like high availability comes bundled with capacity far exceeding actual needs. This is a story of how we nearly spent £180/month on Redis, only to find a solution costing £40 while providing the same high availability guarantees.

The Problem: Redis Pricing Mismatch

When planning our infrastructure, we needed a Redis-class store for coordination primitives critical to our payment system: JWT denylist, rate-limit counters, idempotency keys, and distributed locks. These components sit directly on the money path, making high availability non-negotiable. A node failure during payment processing could lead to double charges or security vulnerabilities.

Our initial assumption was that managed Redis would cost around $70/month for the smallest high-availability tier. This estimate came from memory, not direct console verification. When we actually went to provision the service, we discovered a harsh reality: the smallest high-availability Redis configuration on Google Cloud Platform starts at 5GB, costing $234/month.

This revealed a fundamental issue with cloud database pricing: the capacity floor for high-availability tiers often bears little relation to actual workload requirements. We needed approximately 1.25GB, but the smallest HA option forced us to pay for 4GB of unused capacity purely to gain the replica.

Our Use Cases: Why HA Was Non-Negotiable

To understand why we couldn't compromise on high availability, it's essential to examine our specific use cases:

1. Idempotency keys: Money-path endpoints (orders, payments, refunds, captures) dedupe retries against keys stored in Redis. If a network blip causes a client to retry a payment, the second request finds the existing key and replays the first response instead of charging twice.

2. JWT denylist: Revoked tokens get checked against this store on authentication. While we implement fail-open strategies for availability, the store being operational is critical for security.

3. Rate limiting: Per-business counters that prevent abuse of our APIs.

4. Distributed locks: Short-lived coordination for workers that mustn't double-process tasks.

Three of these four components directly impact either revenue security or actual revenue. The failure mode for idempotency key loss isn't a degraded service—it's double charges to customers. This is why "no HA" was never a viable option for production.

The Redis Pricing Reality Check

When we actually examined the console options for our region (europe-west2), the pricing landscape became clear:

• Redis Basic, 1GB: $39/month, no high availability
• Redis Standard, 5GB (minimum): $234/month, with high availability
• Valkey, pico + 1 replica: $51/month, with high availability

The gap between our initial estimate and reality was staggering. The Redis Standard tier cost 4.5 times what we needed purely to access high availability features.

Redis Basic, while cheaper, offered no replica node. For a service handling payments, this wasn't a viable option. The risk of node failure during payment processing—and the potential for double charges—far outweighed the cost savings.

Valkey: A Wire-Compatible Alternative

Valkey emerged as the ideal solution. As an open-source fork of Redis, it offers wire compatibility with Redis 7.2. This compatibility was critical because our client code uses ioredis, which doesn't distinguish between Redis and Valkey connections.

The migration required changing only one line of code: the host address our application connects to. This zero-code migration was possible because Valkey implements the same protocol, commands, and data structures as Redis.

Beyond compatibility, Valkey offered three additional advantages:

1. True open-source license: Valkey uses a BSD-3 license, while Redis moved to a source-available license (RSALv2/SSPLv1). While not an immediate concern, this portability could be valuable if we ever need to migrate away from GCP's managed offering.

2. Modern networking: Memorystore for Valkey uses Private Service Connect (PSC) rather than the older VPC-peering model. PSC doesn't consume IP ranges from our network and provides finer-grained access control.

3. Decoupled capacity and HA: Valkey allows provisioning a small instance (pico size at ~1.25GB) and separately choosing to add a replica. This decoupling was impossible with Redis Standard, where HA and capacity were bundled at 5GB.

The Pre-Launch Optimization

One additional optimization reduced our costs further: we only enable the replica when we actually need it. During testing, where payment processing isn't live, we run Valkey with zero replicas at approximately $26/month. The day before going live with real payments, we enable the replica, increasing the cost to $51/month.

This approach ensures we're not paying for high availability during development and testing phases where the consequences of node failure are minimal (developer inconvenience rather than financial loss).

Trade-offs: What We Gave Up

Choosing Valkey wasn't without trade-offs. Redis has a longer operational history on GCP, with a deeper track record for reliability and performance. Valkey-on-Memorystore is a newer offering.

However, the wire compatibility made this trade-off manageable. If Valkey proves problematic, reverting to Redis would require only changing the connection string again. This reversibility gave us confidence to adopt the newer technology.

The Broader Lesson: Don't Trust Memory for Cloud Pricing

The most significant lesson wasn't about Valkey—it was about cloud pricing estimation. Our planning number was off by a factor that mattered, not due to carelessness, but because the tier we assumed simply didn't exist.

Cloud pricing pages often hide critical constraints:

• Minimum capacity tiers for high-availability configurations
• Feature bundling that forces overprovisioning
• Regional variations not apparent from generic pricing pages

Before provisioning any managed datastore, ask two critical questions:

1. Do you actually need high availability, or are you about to pay for a replica to protect traffic that can tolerate restarts?
2. Is your capacity requirement driven by your actual workload or by the vendor's minimum tier size?

In our case, the answer to the first question was definitive—we needed HA on the money path. The answer to the second question revealed an opportunity: Valkey allowed us to size our capacity appropriately while still gaining HA.

Conclusion: The Value of Wire Compatibility

This experience highlights the value of wire-compatible alternatives in the database ecosystem. When vendors bundle features in ways that force overprovisioning, alternatives like Valkey can provide the same functionality at a fraction of the cost.

The £140/month we saved isn't just a line item in our budget—it represents the ability to allocate resources to other product improvements. More importantly, it demonstrates that careful evaluation of cloud pricing tiers, combined with awareness of alternative technologies, can prevent significant overprovisioning.

We'll continue to explore the specific implementations of our coordination primitives in future posts, but this story serves as a reminder: when it comes to cloud databases, what you think you know about pricing might be wrong. Always verify in the console for your specific region and use case.

For more information on Valkey, you can visit their GitHub repository and the official documentation. Google's documentation for Memorystore for Valkey provides additional details on the managed offering.