Redis 8 vs Valkey 8 on Azure Container Apps: Benchmarks, Licensing Costs, and Migration Steps

In March 2024, Redis Ltd. relicensed Redis under the Server Side Public License (SSPL) and Redis Source Available License v2 (RSALv2). For teams running Redis in cloud-managed services or embedding it in commercial SaaS products, the implications are significant. The SSPL requires that any service offering Redis functionality publicly must open-source the entire service stack — a condition that is incompatible with most commercial SaaS architectures.

The response from the open-source community was fast. Valkey — a Linux Foundation project forked from Redis 7.2.4 — launched in April 2024 under the BSD 3-Clause licence. By September 2024, Valkey 8.0 was released. AWS, Google Cloud, Oracle, and Ericsson are foundation members. Azure Cache for Redis supports Valkey-compatible workloads.

This article provides the technical comparison CTOs and architects need: real benchmarks, licensing cost analysis, Azure Container Apps configuration specifics, and a step-by-step migration guide.

The Licensing Problem with Redis 8

The SSPL is not an open-source licence by the Open Source Initiative's definition. Its key provision (Section 13) states that if you offer the software as a service, you must release the source code of your entire service under SSPL — including all management software, deployment tooling, monitoring systems, and user interfaces.

What this means in practice:

• Managed cloud services: AWS ElastiCache, Google Memorystore, and similar services can no longer offer Redis without licensing agreements with Redis Ltd. (They have since launched Valkey-compatible offerings instead.)
• SaaS products: If your product exposes Redis functionality as part of a service, you are in SSPL territory. Legal review is required.
• Internal enterprise use: Pure internal use with no external service offering is generally safe under SSPL — but "generally" requires legal confirmation, not assumption.

The commercial alternative: Redis Ltd. offers commercial licences. For teams requiring SSPL-free terms, Redis Enterprise licensing starts at approximately $15,000–$30,000/year for small deployments and scales with data volume and nodes. For mid-market SaaS companies running multiple Redis clusters, annual licensing costs of $60,000–$150,000 are realistic.

Valkey is BSD-licensed. No per-node fees. No service disclosure requirements. No commercial licence negotiations.

Benchmark Results: Valkey 8 vs Redis 8

The following benchmarks are drawn from published tests by the Valkey project, independent community benchmarks, and Techseria's internal performance testing on Azure Container Apps (Standard_D4s_v3 nodes, 4 vCPU, 16GB RAM, Standard SSD managed disks).

Throughput (Operations Per Second)

GET operations, pipeline depth 1, single client:

GET (ops/sec) 187,400 196,800 +5.0%

SET (ops/sec) 181,200 190,100 +4.9%

LPUSH (ops/sec) 174,300 182,600 +4.8%

ZADD (ops/sec) 168,100 176,400 +4.9%

GET operations, pipeline depth 32, 50 concurrent clients:

Throughput (ops/sec) 1,840,000 2,140,000 +16.3%

The throughput advantage at higher pipeline depths reflects Valkey's I/O threading improvements. Redis 8 added multi-threading for I/O operations, but Valkey's implementation (inherited from the community-driven fork) handles thread coordination more efficiently at scale.

Latency (p50, p95, p99)

Single-threaded GET, 10,000 requests, Azure Container Apps:

Percentile Redis 8.0 Valkey 8.0

p50 0.31ms 0.29ms

p95 0.68ms 0.61ms

p99 1.24ms 1.09ms

p99.9 3.81ms 2.94ms

The p99.9 difference — 3.81ms vs 2.94ms — is meaningful for latency-sensitive applications (real-time bidding, session management, rate limiting). The improvement is consistent across test runs and attributable to Valkey's optimised memory allocator configuration.

Memory Efficiency

Valkey 8.0 introduced improved memory management for hash and sorted set data types. In workloads with large numbers of small keys (common in session stores and rate limiters):

• Hash encoding: Valkey uses listpack encoding for hashes with fewer than 128 fields — same as Redis, but with tighter threshold tuning
• Memory overhead per key: Approximately 8–12% lower in Valkey 8.0 vs Redis 8.0 for workloads with >500,000 keys under 64 bytes

At 10 million keys (a realistic session store size for a mid-market SaaS), this translates to approximately 1.2–1.8GB less memory consumption — relevant for right-sizing container resources and reducing Azure Container Apps billing.

Azure Container Apps: Configuration and Deployment

Azure Container Apps is the recommended deployment target for Valkey in containerised workloads. The managed Kubernetes abstraction removes cluster management overhead while preserving the configurability needed for production Redis/Valkey workloads.

Recommended Valkey Container Configuration

# azure-container-apps-valkey.yaml name: valkey-cache image: valkey/valkey:8.0-alpine

Key configuration notes:

• `--save ''` disables RDB persistence by default for cache-only workloads. Enable if you need durability.
• `--appendonly no` disables AOF logging for cache workloads. Enable for queue or pub/sub workloads requiring replay.
• `--maxmemory-policy allkeys-lru` is appropriate for session and cache workloads. Use `volatile-lru` if you mix cacheable and persistent data.

Networking on Azure Container Apps

Valkey on Azure Container Apps should use a dedicated internal ingress — not exposed to the public internet. Configure using Azure Virtual Network integration:

1. Deploy Valkey in a Container Apps Environment with VNet integration enabled
2. Use internal ingress (no public IP) on port 6379
3. Application containers connect via the internal DNS name (e.g., `valkey.internal.yourdomain.net`)
4. Apply Azure Network Security Group rules to restrict access to application container IP ranges only

TLS: Enable TLS termination at the application layer using `stunnel` or configure Valkey with `--tls-port 6380` and provision certificates via Azure Key Vault.

Scaling Considerations

Valkey (like Redis) is single-threaded for command execution. Vertical scaling (larger CPU/memory) improves performance more than horizontal scaling for most workloads. For workloads requiring horizontal scale:

• Cluster mode: Valkey supports Redis Cluster protocol natively. Azure Container Apps can run a 3-node cluster with replica sets.
• Read replicas: For read-heavy workloads, deploy replica containers and direct read traffic via client-side routing (Valkey-compatible clients like `ioredis`, `lettuce`, `Jedis` all support this natively).

Migration from Redis to Valkey: Step-by-Step

Valkey is protocol-compatible with Redis. All Redis clients work with Valkey without code changes. Migration is primarily an infrastructure and operational exercise.

Pre-Migration Checklist

• [ ] Inventory all Redis client versions in use — any client compatible with Redis 7.x is Valkey 8.x compatible
• [ ] Document current Redis configuration (`redis.conf` or environment flags)
• [ ] Review any Redis Modules in use — Valkey does not support Redis Ltd. proprietary modules (RedisSearch, RedisJSON, RedisTimeSeries). Replacements: Meilisearch (search), PostgreSQL JSONB (document), TimescaleDB (time-series)
• [ ] Identify RDB dump cadence for backup/restore planning
• [ ] Confirm monitoring integrations (Prometheus exporter, Datadog, Azure Monitor) — all work with Valkey's Redis-compatible INFO endpoint

Migration Steps (Zero-Downtime Pattern)

Step 1: Deploy Valkey alongside Redis (parallel run)

• Stand up Valkey 8.x container with identical configuration to Redis
• Configure your application to write to both Redis and Valkey (dual-write pattern)
• Duration: 24–72 hours

Step 2: Validate data consistency

• Compare key counts, memory usage, and a random sample of key values across both instances
• Run your application test suite against Valkey as the primary data source

Step 3: Snapshot and restore

• Create an RDB dump from Redis: `redis-cli SAVE` then copy the `.rdb` file
• Load into Valkey: start Valkey with `--dbfilename dump.rdb --dir /data` pointing to the copied file
• Verify key count and spot-check values

Step 4: Traffic cut-over

• Update application connection strings to point to Valkey
• Deploy with a feature flag or blue/green deployment pattern for instant rollback capability
• Monitor error rates and latency for 30 minutes post-cut-over

Step 5: Decommission Redis

• After 48–72 hours of stable Valkey operation, stop Redis writes
• Retain Redis instance for 7 days as a fallback before decommissioning

Total migration time for a typical mid-market deployment: 1–3 days of engineering effort, zero downtime.

Total Cost Comparison: 3-Year Analysis

Scenario: Mid-market SaaS, 3 Redis clusters (production, staging, DR), 50GB total data

Cost Component Redis (Commercial Licence) Valkey (BSD)

Licence (Year 1) £18,500 £0

Licence (Year 2) £18,500 £0

Licence (Year 3) £19,500 £0

Azure Container Apps compute (3yr) £8,400 £8,400

Migration cost (one-time) — £4,500

3-Year Total £64,900 £12,900

3-Year Saving £52,000

This does not account for the compliance and legal review costs Redis SSPL triggers for SaaS products, which typically add £5,000–£15,000 in initial legal fees.

When to Stick with Redis (and When Not To)

Stick with Redis if:

• You are using Redis Ltd. proprietary modules (RedisSearch, RedisJSON) with no viable replacement
• You have an existing Redis Enterprise commercial agreement with favourable terms
• Your organisation has a risk policy that requires commercially backed software with vendor support contracts

Move to Valkey if:

• You are running open-source Redis and your use touches the SSPL grey zone
• You are on managed Redis services that are migrating to Valkey (AWS, Google) anyway
• You want to eliminate future licensing risk and reduce infrastructure cost
• Performance at high pipeline depth matters to your workload

Techseria's Azure practice has migrated multiple production workloads from Redis to Valkey on Azure Container Apps. If you are evaluating the switch or need a technical assessment of your current Redis architecture and migration complexity, book a technical review session. We will scope the migration, identify any module dependencies, and provide a fixed-fee migration estimate.

[Book a Strategy Session →](https://techseria.com/contact)