Microsoft Garnet: a Redis-compatible cache-store with a two-store storage engine

What Garnet replaces, and for whom

Garnet is a remote cache-store from Microsoft Research. The problem it addresses is the one every service hits once traffic grows: a cache tier that stays fast when many clients hold connections and send small batches of commands. The README frames the benefit in exactly those terms, saying Garnet offers better throughput and scalability with many client connections and small batches relative to comparable open-source cache-stores, and that this leads to cost savings for large apps and services.

The audience follows from that. If you run a Redis-compatible cache today and your clients are already written against RESP, Garnet is designed to slot in without touching client code. The README states that Garnet adopts the RESP wire protocol as a starting point, which makes it usable from unmodified Redis clients available in most programming languages, and it names StackExchange.Redis in C# as an example. That is the practical promise: a different server behind the same protocol.

It is not positioned as a drop-in for every Redis deployment. The feature summary lists raw string operations, analytical structures such as HyperLogLog and Bitmap, and object types such as sorted sets and lists, plus multi-key transactions, Lua scripts, stored procedures and modules in C#. Anything outside that list is a question you have to answer yourself.

Inside Tsavorite: two stores, one operation log

The storage layer is called Tsavorite, and the README describes its shape precisely. It consists of two key-value stores whose fates are bound by a unified operation log. The first is the main store, optimized for raw string operations and managed to avoid garbage collection. The second is an optional object store for complex objects and custom data types, covering sorted sets, sets, hashes, lists and geo. Object types are stored on the heap in memory, which the README says makes updates efficient, and in serialized form on disk.

That split is the design decision worth understanding. Strings get one code path, objects get another, and a single log ties them together so recovery and durability see one history rather than two. The README also notes that the team plans to investigate a unified index and log in the future, which is an admission that the current two-store arrangement carries maintenance cost.

The network side is equally specific. Garnet's network layer uses a shared memory design, with TLS processing and storage interactions performed on the network IO completion thread, avoiding thread switching in the common case. The README contrasts this with shuffle-based designs that move data to the appropriate shard on the server. For a cache, the point of that choice is latency: the README claims client latencies often under 300 microseconds at the 99.9th percentile on commodity Azure VMs with Accelerated Networking enabled. Treat that as a vendor benchmark from the project's own site, not an independent measurement.

Tsavorite also carries the database features: thread scalability, tiered storage across memory, SSD and cloud storage, non-blocking checkpointing, recovery, operation logging for durability, and multi-key transactions. Cluster mode adds sharding, replication and dynamic key migration.

Installing Garnet and running a first command

The repository ships a docker-compose.yml that pulls the published image and maps the default RESP port. The image is ghcr.io/microsoft/garnet, the port mapping is 6379:6379, and the compose file sets a memlock ulimit of -1 and mounts a named volume called garnetdata at /data. A comment in the file notes that host mode can be used to avoid Docker NAT.

services:
  garnet:
    image: 'ghcr.io/microsoft/garnet'
    ulimits:
      memlock: -1
    ports:
      - "6379:6379"
    volumes:
      - garnetdata:/data
volumes:
  garnetdata:

Bring it up with the usual compose command from the repository root, and the server should be listening on 6379 with its data volume attached.

docker compose up -d

There is also a .NET tool distribution. The README badges reference the garnet-server package on NuGet, which is the dotnet tool, alongside the microsoft.garnet library package. Check the website documentation for the exact tool invocation before scripting an install; the package names are the part confirmed here.

The Dockerfile reveals one behaviour worth knowing before you expose the server. It patches the default configuration with a sed command that changes "ProtectedMode": "yes" to "ProtectedMode": "no" so the container image is reachable from outside the container. If you build your own image from this Dockerfile, you inherit that change. The runtime stage installs libaio1t64, liburing2 and liblua5.4-0, which tells you the server expects io_uring and Lua support present on the host image.

Once a server is running, any RESP client works. The README's own example is StackExchange.Redis in C#, but the protocol is the contract, not the language.

Where Garnet is the wrong tool

If you need to move a running cluster back to an earlier release, check the website documentation for guidance first. This matters because the project ships frequently: v2.2.3, v2.2.4 and v2.2.5 all arrived within about two weeks of each other in October 2026. Frequent releases are not a defect, but they do mean you should pin a tag rather than follow main.

The two-store design is a second boundary. The optional object store holds complex types on the heap in memory and serialized on disk, and the README says a unified index and log is future work. Until that happens, the string path and the object path are separate mechanisms sharing one log, and you should expect the operational story for object-heavy workloads to differ from the string-heavy case the main store was built for.

Feature coverage is the third. Garnet implements a wide range of APIs, but the README enumerates them rather than claiming parity with every Redis command or module. If your application depends on a specific Redis module or a command not in Garnet's documented set, the RESP compatibility of the client will not save you. Check the command documentation on the project site against the commands your code actually calls.

Finally, the README points to Azure Cosmos DB Garnet Cache for teams that want a managed service with high availability and performance guarantees. If operating a cache server is not something you want to do, the open source repository is the wrong entry point and the managed offering is the one the project itself names.

Garnet against Redis and against Dragonfly

The obvious comparison is Redis, and the difference is architectural rather than protocol-level. Both speak RESP and both accept the same clients, so the client-facing surface is deliberately similar. What changes is what sits behind it. Garnet's server is written in C# on .NET, and its storage engine, Tsavorite, is a purpose-built log-structured store with an explicit split between a string-optimized main store and an object store. Redis's own persistence model is a different lineage, and its extension story is modules in its own ecosystem, whereas Garnet offers stored procedures and modules written in C#, which the README frames as a lower bar for developing custom extensions if your team already writes .NET.

Garnet's README compares its throughput and scalability to comparable open-source cache-stores and links to benchmarking charts on the project site, and the vector-set preview links to a DiskANN comparison against other vector databases. Those are the project's own numbers. If you are choosing between Garnet and another Redis-compatible server, the honest position is that the published charts come from the vendor and you should reproduce the workload shape that matters to you: connection count, batch size, value size, and whether your data is strings or objects.

One genuine differentiator is tiered storage. Tsavorite supports memory, SSD and cloud storage tiers. A cache that can spill to SSD and cloud storage is a different proposition from one that assumes the working set fits in RAM, and it changes the cost model for large datasets.

Licence, maintenance and upgrade cost

Garnet is MIT licensed, and the repository carries a separate NOTICE.md alongside the LICENSE file. MIT is permissive, so redistribution and commercial use are broadly allowed, but the NOTICE file exists for a reason and should be carried along with any redistribution. That is a description of what the repository contains, not legal advice; if you ship Garnet inside a product, have counsel read both files.

The maintenance picture is active. The default branch is not archived, and the last push was on 2026-11-02, a few days after the most recent release, v2.2.5 on 2026-10-28. The project has a public issue tracker on GitHub, a Discord community linked from the README, a SECURITY.md and a SUPPORT.md file at the repository root, and a published paper accepted at VLDB 2026. A research project with a paper, a release train and a Discord is not abandoned.

The upgrade cost is where you should be careful. Three releases (v2.2.3 to v2.2.5) inside two weeks means fixes arrive quickly, and it also means the surface you are running can change under you. For a cache, that usually matters less than for a primary database, because a cache can often be flushed and refilled. If you are relying on Garnet's persistence and recovery features, the calculus changes, and you should test recovery on your own data before you depend on it.

Editorial conclusion

Garnet fits teams that already run Redis clients and want a .NET-based server with tiered storage and cluster sharding built in, and it is a poor fit if you depend on Redis modules that Garnet does not implement or on a fully managed service you do not operate. Before adopting, verify three things against your own workload: that the RESP commands your client actually issues are implemented, that your persistence expectations match what the operation log and checkpointing provide, and that the licence terms of the MIT-licensed code plus the NOTICE.md file suit your distribution model. The repository's default branch was last pushed on 2026-11-02, so the code is moving; pin the release tag you deploy rather than tracking main.

Frequently asked questions

Official sources

1. License: MIT
2. microsoft/garnet on GitHub
3. Project website
4. README
5. Releases