# Garnet: Microsoft Research's Redis-Compatible Cache-Store Built on .NET

> Garnet is a remote cache-store from Microsoft Research that speaks the RESP protocol, making it a drop-in target for existing Redis clients. It is built on C# and .NET, uses a custom storage engine called Tsavorite, and targets deployments where many concurrent client connections and low tail latency matter.

**microsoft/garnet** — Garnet is a remote cache-store from Microsoft Research that offers strong performance (throughput and latency), scalability, storage, recovery, cluster sharding, key migration, and replication features. Garnet can work with existing Redis clients.

- Repository: https://github.com/microsoft/garnet
- Website: https://microsoft.github.io/garnet/
- Stars: 12,034 · Forks: 709
- Language: C#
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-garnet

## What Garnet Is and the Problem It Targets

Garnet addresses the performance characteristics that appear at scale in cache-dependent services: high client connection counts, small request batches, and the need for very low tail latency. The README describes its target scenario as large apps and services where the cost of many client connections drives infrastructure spending.

The project adopts the RESP wire protocol as its external interface. RESP is the protocol Redis uses, which means any Redis client library, including StackExchange.Redis for C#, can connect to Garnet without modification. This compatibility removes the client-side migration cost, which is typically the largest friction point when switching cache-stores.

Garnet comes from Microsoft Research and is positioned as a research-grade system that has been hardened for production use. The README notes it is written against the latest .NET technology, targeting both Linux and Windows with equal treatment. A fully managed hosted version, Azure Cosmos DB Garnet Cache, is available for teams who do not want to operate the server themselves.

## The Tsavorite Storage Engine and Its Two Stores

The core design decision in Garnet is the Tsavorite storage engine, which underpins all data operations. Tsavorite exposes a narrow API of four operations: read, upsert, delete, and atomic read-modify-write. On top of this API, Garnet implements the full RESP surface. The narrow waist separates parsing and query processing from storage concerns such as concurrency, storage tiering, and checkpointing.

Tsavorite operates two distinct stores. The main store is optimised for raw string operations and manages memory carefully to avoid garbage collection. The object store handles complex types including sorted sets, sets, hashes, lists, and geo-spatial data. Object store entries are kept in memory as .NET heap objects, which makes updates efficient, and serialised to disk for persistence. The two stores share a unified operation log that keeps their states consistent.

The storage engine supports tiered storage across memory, SSD, and cloud storage, non-blocking checkpointing, operation logging for durability, and thread scalability. Multi-key transactions use two-phase locking. The cluster mode adds sharding, replication, and dynamic key migration, allowing an operator to rebalance shards without taking the cluster offline.

Two preview features appear in the repository: Vector Sets, which implement approximate nearest-neighbour search using the DiskANN algorithm, and Range Index, which adds secondary range and equality indexes over keys using an algorithm called Bf-Tree.

## Running Garnet with Docker Compose

The repository ships a docker-compose.yml that starts a single Garnet node listening on port 6379, matching Redis's default port:

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

The image is pulled from GitHub Container Registry. The memlock ulimit is set to unlimited, which allows the process to lock memory pages and avoid swapping, a standard configuration for latency-sensitive data stores. The garnetdata volume persists data across container restarts.

The Dockerfile in the repository shows the build process uses .NET SDK 10.0 for compilation and targets the .NET 10 runtime. The build compiles from source using dotnet publish with the net10.0 target framework, then copies the result into a runtime-only base image. This means pulling the prebuilt image from the registry is the practical starting point for evaluation; building from source requires the full .NET 10 SDK.

## API Coverage, Custom Extensions, and Lua Support

Garnet implements a broad range of RESP API operations across three categories. Raw string operations include get, set, and key expiration. Analytical operations cover HyperLogLog and Bitmap commands. Object operations include sorted sets, sets, hashes, lists, and geo-spatial commands.

Beyond the RESP API, Garnet allows custom operations in C#. Teams can write custom operations against both raw string types and custom object types, which are then callable as server-side stored procedures. The README frames this as having a lower bar for extension development because the logic runs in C# rather than requiring a separate runtime or module format. Garnet also supports Lua scripts, compatible with Redis Lua scripting.

The network layer supports TLS through the .NET SslStream library and includes basic access control. The README describes the network design as shared memory, with TLS processing and storage interactions performed on the same IO completion thread to avoid thread switching overhead. This design choice places the data access on the same CPU as the incoming packet, aiming to improve cache locality.

## Where Garnet Is Not the Right Choice

Garnet is written in C# on .NET. Teams whose operational tooling assumes a C-based Redis binary, including specific monitoring agents, kernel tuning guides written for Redis's memory model, or orchestration templates that reference Redis-specific config keys, will find that Garnet does not behave identically to Redis in every operational dimension even when the wire protocol is compatible.

The extension model for custom operations uses C# stored procedures, not the Redis Modules API. Projects that depend on existing Redis modules, such as RedisJSON, RediSearch, or RedisTimeSeries, cannot load those modules into Garnet. The equivalent functionality would need to be reimplemented as a Garnet stored procedure or use a Garnet-native alternative where one exists.

The Vector Sets and Range Index features are marked as preview. The README includes initial performance comparisons for Vector Sets against other vector databases, but preview status means the API and behaviour may change before a stable release.

Azure Cosmos DB Garnet Cache, the managed version, is an Azure-specific offering. Teams using other cloud providers or running fully on-premises have no equivalent managed option and must operate the server themselves.

## Maintenance Pace, Research Lineage, and MIT Licence

The last push to the repository was on 2026-09-28, and recent releases show a weekly cadence: v2.1.6, v2.1.7, and v2.1.8 were all published in September 2026. A research paper on Garnet has been accepted to VLDB 2026, the conference record for very large databases, authored by researchers at Microsoft Research.

The project is licensed under the MIT licence, which is permissive. Commercial use, modification, and redistribution are all permitted without copyleft obligations. The NOTICE.md file in the repository covers attribution for third-party components used by Garnet.

For teams already using Redis who want a comparison, the README points to benchmarking documentation at microsoft.github.io/garnet/docs/benchmarking/overview. The performance claims in the README describe relative advantages in throughput and scalability under many concurrent connections with small batches, and a documented p99.9 latency of often less than 300 microseconds on Azure VMs with Accelerated Networking. The README does not claim these results are independent of the infrastructure configuration.

## Conclusion

Teams already running Redis who want to evaluate a drop-in alternative with better throughput at high client concurrency should start with the Docker Compose file from the repository: the server listens on the same port 6379, so existing client code requires no changes. Teams using Redis-specific extensions not covered by the RESP protocol or relying on Redis modules should confirm compatibility before migrating, as Garnet implements its own extension model through C# stored procedures rather than the Redis Modules API.

## FAQ

### Can Garnet use existing Redis client libraries?

Yes. Garnet implements the RESP wire protocol, which is the same protocol Redis uses. Any Redis client library, such as StackExchange.Redis for C#, can connect to Garnet without modification.

### How do you install and run Garnet?

The repository ships a docker-compose.yml that pulls the ghcr.io/microsoft/garnet image and starts the server on port 6379. Running docker compose up from the repository root starts a single node with a persistent data volume.

### Does Garnet support Redis clustering and replication?

Yes. Garnet has a cluster mode that supports sharding, replication, and dynamic key migration for rebalancing shards. The README describes these as fully-featured cluster capabilities.

## Sources

- [License: MIT](https://github.com/microsoft/garnet/blob/main/LICENSE)
- [microsoft/garnet on GitHub](https://github.com/microsoft/garnet)
- [Project website](https://microsoft.github.io/garnet/)
- [README](https://github.com/microsoft/garnet/blob/main/README.md)
- [Releases](https://github.com/microsoft/garnet/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-garnet