The in-memory data store space that .NET teams once took for granted fractured in 2024. Redis changed its license, the community forked it, and Microsoft Research shipped a .NET-native challenger. Today, when your team reaches for a distributed cache or fast key-value store, you are no longer defaulting to Redis by reflex — you are making an architectural decision between three genuinely different options: Redis, Valkey, and Garnet.
This article helps you make that call deliberately. If you want to go deeper on implementing whichever store you choose — including how it wires into IDistributedCache and HybridCache inside a real production API — the full implementation with edge cases covered is on Patreon.
Understanding which server to run is only half the picture. The other half is knowing how to integrate it correctly into your caching layer. Chapter 9 of the ASP.NET Core Web API: Zero to Production course covers IDistributedCache with Redis, HybridCache (L1 + L2 combined with stampede protection), and when to reach for each abstraction — all inside a running production-grade codebase.
What Caused This Three-Way Split?
In March 2024, Redis Ltd. changed Redis's license from BSD-3-Clause to a dual RSALv2/SSPLv1 model. The Server Side Public License is not OSI-approved, which meant major Linux distributions dropped Redis from their repositories, and cloud providers lost the right to offer managed Redis without a commercial arrangement.
The response was immediate. AWS, Google Cloud, Oracle, and a coalition of other companies forked the last open-source Redis release and donated it to the Linux Foundation under the name Valkey. Within months, distributions that had dropped Redis started shipping Valkey instead.
Then, in May 2025, Redis Ltd. reversed course — adding the AGPLv3 as an additional licensing option starting with Redis 8. Redis is technically open source again, but many teams had already migrated or committed to alternatives, and trust in the project's licensing stability had taken a permanent hit.
Meanwhile, Microsoft Research had been quietly building Garnet — a RESP (Redis Serialization Protocol) compatible cache server written entirely in .NET, designed to exploit modern multi-core hardware more aggressively than Redis's traditionally single-threaded architecture could.
The result: three credible options, each with a different trade-off profile.
The Three Contenders at a Glance
Redis 8 (AGPL) is the original. It is the most feature-complete, the best-documented, the most widely deployed, and has the broadest ecosystem of integrations, tooling, and cloud-managed offerings. Starting with version 8, it is licensed under AGPLv3 — open source by the OSI definition, but with copyleft implications that matter if you ship Redis-adjacent software as a service.
Valkey is a direct fork of the last BSD-licensed Redis release (7.2.x), maintained by the Linux Foundation with backing from AWS, Google, Oracle, Snap, and others. It is a drop-in replacement — same commands, same data structures, same client protocol. Valkey 8.x has added multi-threaded I/O improvements, and benchmarks show it delivering 8–20% higher throughput than Redis in comparable conditions, along with lower P99 latency under sustained load.
Garnet is Microsoft Research's re-implementation of the RESP protocol on top of the .NET runtime. It is not a fork of Redis — it is a ground-up rebuild that targets the same wire protocol. Because it runs on .NET, it takes advantage of SIMD acceleration, zero-copy socket I/O through System.Net.Sockets, and modern thread-pool scheduling. Benchmark results show Garnet reaching significantly higher throughput than Redis on write-heavy workloads at high connection counts — in some configurations, exceeding Redis throughput by over 100% on write paths. It has a first-class integration in .NET Aspire for local development orchestration.
How the .NET Client Stack Sees All Three
From a .NET application's perspective, this choice is transparent. StackExchange.Redis — the de facto .NET client for Redis-compatible stores — explicitly supports Redis, Garnet, Valkey, AWS ElastiCache, and Azure Managed Redis. The same IConnectionMultiplexer abstraction, the same IDistributedCache registration, the same HybridCache integration — nothing changes in your application code when you swap the server.
That is the critical lever for .NET teams: the migration cost is almost entirely in infrastructure (container images, Helm charts, connection strings) rather than code. An application that uses IDistributedCache through the standard AddStackExchangeRedisCache(...) registration can switch from Redis to Valkey to Garnet by changing one line in appsettings.json.
The only meaningful code-level concern is if you use advanced Redis-specific features — modules like RedisSearch, RedisJSON, or RedisBloom — because these are not replicated in either Valkey (at parity, community modules are still maturing) or Garnet (not yet supported as of mid-2026).
Side-by-Side Comparison
| Dimension |
Redis 8 (AGPL) |
Valkey 8.x |
Garnet |
| License |
AGPLv3 + commercial |
BSD-3-Clause |
MIT |
| Architecture |
Single-threaded event loop (+ I/O threads) |
Multi-threaded I/O |
Multi-threaded, .NET runtime |
| .NET client |
StackExchange.Redis ✓ |
StackExchange.Redis ✓ |
StackExchange.Redis ✓ |
| Managed cloud option |
Redis Cloud, Azure Cache, ElastiCache |
AWS ElastiCache Valkey, Upstash |
Self-hosted / .NET Aspire |
| Modules (Search, JSON, Bloom) |
Full support |
Partial / maturing |
Not yet supported |
| .NET Aspire integration |
Via Redis container |
Supported |
First-class |
| Write throughput (high concurrency) |
Baseline |
~15–30% above Redis |
Up to ~100%+ above Redis |
| Cluster / Sentinel |
Full |
Full |
Limited (improving) |
| Community maturity |
Very high (10+ years) |
Growing fast |
Early production |
| Copyleft risk |
Yes (AGPL) |
No |
No |
When to Choose Redis
Choose Redis when your team is already running it in production and has no legal or licensing pressure to migrate. Redis 8 under AGPL is a genuine open-source option for most application scenarios — the copyleft clause of AGPL only becomes a concern when the software you are distributing is itself a Redis-adjacent service or tool. For most SaaS and enterprise applications that consume Redis as an infrastructure component, AGPL is effectively a non-issue.
Redis also wins when you depend on Redis modules — particularly RedisSearch for full-text search within Redis, or RedisJSON for structured JSON storage. These are mature, production-tested capabilities with no current equivalent in Valkey or Garnet.
If your team is using a managed cloud offering (Azure Cache for Redis, AWS ElastiCache for Redis, or Redis Cloud), the migration argument weakens further — the managed layer already handles upgrades, replication, and failover, and switching providers has a real operational cost of its own.
When to Choose Valkey
Valkey is the strongest argument for teams that want to move off Redis without accepting any architectural risk. It is the only option of the three that was explicitly designed to be a drop-in replacement at the data-structure, command, and wire-protocol level.
If your team made the pragmatic call to migrate during the 2024 license uncertainty, Valkey is where you likely landed — and it has proven itself in production at scale. Snap reportedly cut over a million dollars per year from their ElastiCache bill by migrating to Valkey on AWS. The multi-threaded I/O improvements in Valkey 8.x make it a measurable upgrade over Redis in throughput-constrained workloads without requiring any application changes.
Valkey is also the best choice when you want a permissive open-source license (BSD-3) and a strong foundation guarantee. The Linux Foundation's governance model means no single company can repeat the license-change scenario that created this choice in the first place.
When to Choose Garnet
Garnet is the right choice for teams with two specific conditions: they are building .NET-first infrastructure, and they have write-heavy, high-concurrency workloads where raw throughput matters.
Because Garnet is built on .NET, it is a natural fit for .NET Aspire-based local development setups — you get health checks, Aspire dashboard integration, and a consistent developer experience without running a separate Linux container image. For teams building microservices with .NET Aspire where the cache is a supporting service, Garnet's first-class Aspire integration is a genuine ergonomic advantage.
The caution: Garnet's production maturity outside of Microsoft's own infrastructure is still developing. Cluster mode and Sentinel are improving but not at Redis or Valkey parity. If you need proven high-availability clustering at scale, Garnet is not the safe default yet — though that is likely to change as the project matures.
Real-World Trade-offs Enterprise Teams Should Consider
Licensing posture. AGPL has specific implications for software companies. If your team builds tools or platforms that integrate with Redis at the library level and distribute them to customers, a legal review of AGPL applicability is worthwhile before staying on Redis 8. For application teams consuming Redis as infrastructure, this is generally not a concern.
Migration overhead. If you are on a managed Redis cloud service, the server choice is partially decoupled from your application — your cloud provider decides which server runs behind the endpoint. AWS ElastiCache now supports both Redis and Valkey; migrating between them is a cluster engine change, not an application change.
Operational knowledge. Redis has a decade's worth of runbooks, Stack Overflow answers, and engineers who know it deeply. Switching to Valkey or Garnet means your operations team is working with a smaller community knowledge base, even if the technical implementation is similar.
Data structure parity. All three support strings, hashes, lists, sets, sorted sets, streams, and pub/sub. The divergence is almost entirely in ecosystem features (modules, cluster tooling, managed services) rather than core data structures.
For deeper guidance on how to wire whichever option you choose into IDistributedCache and avoid the most common caching mistakes in ASP.NET Core APIs, the Redis Caching Patterns for ASP.NET Core APIs article covers the cache-aside, write-through, and invalidation patterns in detail. And if your use case involves distributed locking rather than caching, Distributed Locking in .NET: Redis vs SQL Server vs Azure Blob walks through the trade-offs at the locking layer.
The Recommendation
For most .NET teams in 2026, the choice simplifies like this:
Already on Redis with no licensing concerns → stay. Redis 8 under AGPL is a solid, stable option with the richest ecosystem. There is no compelling reason to migrate unless you are under licensing scrutiny or you want to extract more throughput.
New projects or teams that migrated during 2024 → default to Valkey. It is the most risk-neutral choice: BSD license, drop-in compatibility, active Linux Foundation governance, and measurably better throughput than Redis on modern hardware.
High-throughput .NET-first teams building on .NET Aspire → evaluate Garnet. If writing 500K+ operations per second matters to your workload and you are comfortable being on the leading edge of a maturing project, Garnet's .NET-native architecture is a genuine advantage. Keep a fallback plan to StackExchange.Redis on Valkey if cluster requirements grow.
Frequently Asked Questions
Does switching from Redis to Valkey require code changes in ASP.NET Core?
No. If your application uses IDistributedCache with AddStackExchangeRedisCache(...), switching to Valkey is a connection string change. StackExchange.Redis communicates using the RESP protocol, which Valkey fully implements. The application code does not know which server is on the other end.
Can Garnet replace Redis in a .NET Aspire application today?
Yes — .NET Aspire has a first-class Garnet integration with built-in health checks and dashboard visibility. For local development and single-node deployments, Garnet is production-ready. For multi-node clustered production deployments, Garnet's cluster support is still maturing, and Valkey or Redis are the more cautious choices.
Is Redis safe to use again after the AGPL relicensing?
For most application teams, yes. The AGPL license is OSI-approved open source, and Redis 8 is a legitimate open-source project again. The copyleft risk is specific to teams building and distributing Redis-adjacent software as a service. If you are just using Redis as a distributed cache inside a SaaS product, AGPL does not impose meaningful obligations.
Redis's core architecture is single-threaded for command execution, relying on non-blocking I/O to handle concurrency. Garnet's .NET architecture is fully multi-threaded — it can distribute both I/O and command processing across all available CPU cores, and it uses SIMD-accelerated string operations and zero-copy socket APIs from the .NET runtime. This difference becomes significant when a server has many cores and is handling a large volume of concurrent write operations.
Which option is supported on Azure?
Azure Cache for Redis supports Redis and Valkey as engine options. There is no Azure-managed Garnet offering at this time. For teams that want a managed Garnet experience, the primary path today is self-hosting via containers in Azure Container Apps or AKS, or running it through .NET Aspire in development environments.
Does Valkey support all Redis commands?
Valkey 8.x supports virtually all Redis commands used in typical application workloads. The divergence is primarily at the module ecosystem level — Redis-specific modules (RedisSearch, RedisJSON, RedisBloom) are not available in Valkey, though community-driven equivalents are under active development. Core data structures (strings, hashes, sets, sorted sets, lists, streams, pub/sub) are fully supported and compatible.
Should teams already on Valkey migrate back to Redis after the AGPL change?
No compelling technical reason exists to migrate back. Valkey is performing well, has a strong governance model, and carries a more permissive license. The main reason to reconsider Redis would be if you have specific dependencies on Redis-only modules or managed services. For teams that migrated to Valkey and are running it correctly, staying on Valkey is the rational choice.
