Microsoft Research open-sourced Garnet in March 2024, presented on its official blog[1], with a far from modest promise. It is a key-value cache server compatible with the Redis protocol, but sustaining two to three times more operations per second on modern hardware. The promise rests on an architecture written from scratch in .NET, with the operating system’s thread pool and async machinery as central pieces.

Nearly twenty months later, Garnet has stable releases out 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 machines with dozens of cores; 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 a small or midsize team, 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. 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 and a storage backend called Tsavorite that manages memory and disk in a hybrid way. It adds 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 machine with dozens of cores. An October 2025 academic study compares Redis, Valkey, Garnet, and Dragonfly under realistic Kubernetes workloads (arXiv[3]). It confirms Garnet’s better scalability against Redis and KeyDB as client sessions grow, with nuance depending on the workload.

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 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: 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 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 one specialized tool, not the Redis of the future. It fills a specific niche well: 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.

Frequently asked questions

Can I connect my existing Redis clients to Garnet without changing code?

In principle yes: Garnet speaks the Redis protocol and any existing Redis client can connect unchanged. But protocol support is not 100 percent complete: the most-used operations are covered, while less frequent commands and some advanced data structures have partial or missing implementations. Before migrating a complex application, audit which commands it actually uses.

How much faster is Garnet than Redis?

Per Microsoft's published benchmarks, Garnet sustains two to three times more operations per second than Redis on machines with dozens of cores. It distributes requests across multiple core-affinity threads instead of serializing them on a single thread. An October 2025 academic study confirms that better scalability against Redis and KeyDB as client sessions grow, with nuance depending on the workload.

When does it make sense to choose Garnet over Redis or Valkey?

The first of three scenarios is when you need a high-performance cache on a single 32- or 64-core machine and want to avoid the complexity of a Redis cluster. Second, when your platform is already on .NET and you want to reduce the technology surface. Third, when the use case leans toward a database, with datasets larger than memory, durability and integrated replication. For most small and midsize teams, Valkey or Redis remain the reasonable answer in 2025.

Sources

  1. official blog
  2. GitHub
  3. arXiv
  4. AWS ElastiCache