Garnet – A new remote cache-store from Microsoft Research

Original Article ↗ Hacker News Discussion ↗

Microsoft Research’s new project Garnet aims to be a high‑performance, Redis‑compatible remote cache and store, built in C# on top of the Tsavorite/FASTER storage engine. Commenters highlight benchmarks showing significantly higher throughput and competitive tail latencies versus Redis and Dragonfly, while noting trade-offs such as partial command compatibility, non-atomic multi-key operations in a multithreaded design, and the fact it’s still a research project with uncertain long-term support. The release also rekindles debate over .NET’s performance capabilities, Azure’s caching strategy and pricing, and trust in vendors’ licensing and telemetry practices after recent changes in the Redis ecosystem.

Performance & architecture

  • Benchmarks show Garnet’s GET throughput far exceeding Dragonfly and Redis, with comparable or better tail latencies; some infer Redis could use major optimizations.
  • Implemented in C# with extensive unsafe and low-level memory work; many see this as proof .NET can match C/C++ performance when carefully tuned.
  • Storage layer Tsavorite (forked from FASTER) offers thread scalability, tiered storage, non-blocking checkpoints, logging, transactions, and improved memory reuse.
  • Some suspect gains come more from data structures/algorithms and multithreading than from language choice alone.
  • Questions remain about where it performs poorly and how it behaves on smaller, less “beefy” instances than the 72 vCPU benchmark box.

Redis compatibility & semantics

  • Marketed as working with existing Redis clients, but API compatibility is incomplete; streams support is unclear.
  • Redis is single-threaded and fully atomic per command, whereas Garnet is multi-threaded and explicitly notes that MSET is not atomic unless expressed as a transaction. Some see this as a serious “drop-in replacement” caveat.
  • Redis is still considered “good enough” and extremely battle-tested for most use cases; many prefer to stick with it despite Garnet’s numbers.
  • Redis clustering mitigates single-threaded limitations but introduces its own complexity.

.NET ecosystem & GC discussion

  • Thread discusses how .NET and Java JITs, GC, and profiling can sometimes outperform hand-written C/C++ code, especially with polymorphism and managed memory strategies.
  • .NET’s spans, structs, unsafe pointers, and off-heap options are cited as powerful performance knobs; debate over escape analysis and stack allocation details.
  • There is disagreement about library ecosystem maturity and toolchain: some say .NET libraries are complete and high quality; others see gaps vs JVM and note heavy dependence on Visual Studio for the “best” experience.

Azure, Windows, and deployment

  • Strong interest in Garnet as a native, high-performance cache on Windows Server and Windows containers, avoiding WSL or archived Redis ports.
  • Some want it embedded in Azure App Service or similar, with node-local caches replicated to nearby nodes, arguing network hops dominate latency anyway.
  • K8s + Cilium “local redirect” patterns are mentioned as a way to get locality benefits with other caches.

Licensing, governance & trust

  • Garnet is MIT-licensed but requires a CLA; some view this as legal housekeeping, others as enabling relicensing.
  • Concerns raised about Microsoft’s patent posture and Microsoft Research projects often stalling, balanced by notes that Garnet is already used internally and could become an Azure service.
  • Several contrast Garnet’s open license with Redis’ shifting licensing and ecosystem forks, though some still trust Redis more due to history and simplicity.