Microsoft Garnet: a high-performance cache alternative
Updated: 2026-07-07
Microsoft Research open-sourced Garnet in March 2024, presented on its official blog[1], with a far from modest promise: a key-value cache server compatible with the Redis protocol, but with significantly higher performance on modern hardware thanks to an architecture written from scratch in .NET, with the operating system’s thread pool and async machinery as central pieces. Nearly twenty months later, with several stable releases and public deployments in Microsoft’s internal services, it’s time for an honest assessment of where the project stands, what it actually delivers, and in which cases it is worth considering over Redis or alternatives such as Valkey.
Key takeaways
-
Garnet is written in .NET 8 with multiple core-affinity threads and a storage backend called Tsavorite that manages memory and disk in a hybrid way.
-
Redis protocol compatibility is the project’s most strategic decision: any existing Redis client can connect to Garnet unchanged.
-
Per Microsoft’s benchmarks, Garnet sustains two to three times more operations per second than Redis on many-core machines; third-party benchmarks confirm similar numbers with nuance.
-
The Garnet ecosystem is immature: observability tools, specialized clients, Kubernetes operators, and cloud provider integrations are scarce.
-
For most small and midsize teams, Valkey or Redis remain the reasonable 2025 answer; Garnet enters the picture once you’ve exhausted the simple alternatives and need that next step in performance without moving to a cluster.
What it is and where it comes from
Garnet was born as a research project inside Microsoft Research’s systems group. The starting point was a concrete observation: Redis, despite being excellent, was written when servers had four cores and 16 GB of memory, and its single-threaded architecture makes poor use of today’s machines with 64 or 128 cores and hundreds of gigabytes. Redis addresses the problem partially through clustering, but a single Redis process is still unable to saturate a large machine.
Garnet was written to exploit that hardware: it uses multiple core-affinity threads, a storage backend called Tsavorite that manages memory and disk in a hybrid way, and asynchronous I/O primitives when the operating system offers them. The code, under an MIT license, is published on GitHub[2].
Redis protocol compatibility is the project’s most important strategic decision. Any existing Redis client can connect to Garnet unchanged. This isn’t a startup chasing funding; it’s an industrial lab releasing code.
The numbers Microsoft has published are aggressive: by its own benchmarks, Garnet sustains two to three times more operations per second than Redis on a many-core machine. An October 2025 academic study comparing Redis, Valkey, Garnet, and Dragonfly under realistic Kubernetes workloads (arXiv[3]) confirms Garnet’s better scalability against Redis and KeyDB as client sessions grow, though with nuance depending on the workload, as usually happens.
Architecture: what makes Garnet different
The most interesting technical piece is the Tsavorite storage engine, an evolution of the earlier research project called FASTER. Tsavorite can run purely in memory like Redis, but also in a hybrid memory-plus-disk mode, managing an address space larger than the physically available memory. That matters because it lets a single server handle datasets that don’t fit in RAM without jumping to an additional node.
The second piece is concurrency. While Redis serializes all work on a single thread, Garnet has an internal scheduler that distributes requests across core-affinity threads. For workloads where requests are independent, this architecture exploits the 32 or 64 cores of a modern server in a way Redis simply can’t.
The third differentiator is native support for persistent storage and replication. Garnet includes asynchronous primary-secondary replication with failover, similar to Sentinel but built in, plus persistence through Tsavorite-store checkpoints.
Comparison with Redis and Valkey
The relevant comparison in 2025 goes beyond Redis: it also includes Valkey, the open fork born when Redis changed its license in March 2024. Valkey has kept API compatibility and an open license, is already the default in AWS ElastiCache[4], and has the backing of the Linux Foundation.
-
Valkey is the conservative option: identical Redis protocol, an evolved single-threaded architecture. Its performance is comparable to Redis 7, maybe slightly better, but it doesn’t aim to be an architectural revolution.
-
Dragonfly, the other serious contender, is closer to Garnet in ambition but different in implementation: it’s written in C++ and uses a shared-nothing multi-thread model.
-
Garnet occupies a spot of its own: very high performance on big hardware, an architecture unlike the others, the backing of an industrial research lab, and the differentiating fact of being written in .NET. That last point cuts both ways: for teams already living in the .NET ecosystem, Garnet is natively integrable and auditable; for teams that aren’t, it means introducing a significant runtime dependency that other products don’t require.
Where it pays off to consider it
Three scenarios deserve serious Garnet evaluation:
-
When you need a very high-performance cache on a large machine and a monolithic Redis isn’t enough. Instead of jumping to a Redis cluster with the operational complexity that implies, a single Garnet node on a server with 32 or 64 cores can cover the load.
-
When your platform is already on .NET and you want to reduce the technology surface. Operating both a .NET service and a Redis instance means two separate ecosystems for monitoring, deployment, and staffing.
-
When the use case leans toward a database rather than a pure cache: datasets larger than memory, a need for durability, a requirement for integrated replication.
Limitations and caveats
Not everything is favorable:
-
The Garnet ecosystem is immature compared to Redis: observability tools, specialized clients, Kubernetes operators, and cloud provider integrations are scarce.
-
Redis protocol support isn’t 100 percent complete. The most-used operations are covered, but less frequent commands and some advanced data structures have partial or missing implementations. Audit which commands your application actually uses before migrating anything complex.
-
The operational learning curve: Garnet on .NET brings a runtime with its own characteristics, including garbage-collector tuning and managed-memory behavior under pressure.
How to think about the decision
Garnet isn’t going to displace Redis in the short term, and probably not in the medium term either. Redis and Valkey have too much inertia: an ecosystem, trained staff, documentation accumulated over fifteen years, integrations on every platform.
For most small and midsize teams, the reasonable answer in 2025 is still Valkey if you want open and compatible, or Redis if you’re already comfortable with the license. Garnet becomes an option worth considering once you’ve exhausted the simple alternatives and need that next step in performance without moving to a cluster.
Knowing when it applies is worth more than deciding upfront whether you like it more or less than the alternatives.
Conclusion
Garnet is a specialized tool among several, not the Redis of the future. It fills a specific niche well: very large loads on single machines, pure .NET environments, and cases needing durability and hybrid memory-disk. Outside that niche, the more mature options remain the better choices.
This article is also available in Spanish: Garnet de Microsoft: alternativa de caché de alto rendimiento.
