microsoft/FASTER: A Persistent Log and Key-Value Store for C# and C++

The problem FASTER targets: large state that must survive a restart

The README frames the problem directly: managing large application state easily, resiliently, and with high performance is one of the hardest problems in the cloud today. FASTER offers two artifacts to tackle it. FASTER Log is a concurrent persistent recoverable log, iterator, and random reader library in C#. FASTER KV is a concurrent key-value store and cache available in C# and C++, designed for point lookups and heavy updates. The intended audience is engineers building systems where state is too large to keep comfortably in memory and where a restart cannot mean rebuilding from scratch. The README states that FASTER supports data larger than memory by using fast external storage, local or cloud, and that it supports consistent recovery using a non-blocking checkpointing technique. That checkpointing design is the part worth paying attention to: the README says it lets applications trade off performance against commit latency rather than forcing one fixed durability cost on every write.

How the log and the key-value store actually fit together

FASTER Log and FASTER KV are separate artifacts with different shapes. The log is a durable append-oriented structure with an iterator and a random reader, and the README states it supports very frequent commit operations at low latency and can quickly saturate disk bandwidth. It ships with sync and async interfaces, handles disk errors, and supports checksums. FASTER KV sits on the same log-based machinery but exposes a hybrid hash index over a record log: point lookups and heavy updates are the workload it is designed for, and the README lists both C# and C++ implementations. The repository layout reflects the split: cc/ holds the C++ work and cs/ holds the C# work, with docs/ carrying the documentation and azure-pipelines.yml plus azure-pipelines-full.yml driving CI. The persistent, recoverable, concurrent and multi-threaded topics on the repository describe the same design intent. What the README does not document is the internal record format or the exact hash index layout, so anyone who needs those details has to read the source under cs/ and cc/ rather than the front page.

Getting the C# package and committing a first log entry

The README does not carry a step-by-step install section. It shows the NuGet badge for Microsoft.FASTER.Core and points to aka.ms/FASTER for getting started, so the package is the entry point for C# users. The README gives no install command of its own, so there is no fenced snippet to copy here: the package name Microsoft.FASTER.Core is the fact the README supplies, and the install step is whatever your normal NuGet workflow is for that package. The README describes FASTER Log as a concurrent persistent recoverable log with sync and async interfaces, so the first real use is to open a log, commit a record, and read it back. The README does not reproduce a complete code sample, and the exact constructor and session API are not spelled out in the text above, so treat any snippet as something to check against the source under cs/ before you rely on it. The behaviour to look for is a commit that returns at low latency and a subsequent read that returns the value you wrote, followed by a restart that recovers the same value from the log. The C++ side lives under cc/ and is built from source rather than from NuGet, since the README only advertises the NuGet package for the C# artifact.

The maintenance status is the first thing to weigh

The README carries an explicit notice: this repository is no longer actively maintained. The last push was on 2026-08-19, and the most recent tagged release in the list is v2.6.5 from 2024-05-07, with v2.6.4 and v2.6.3 preceding it in 2024. That gap between the last release and the last push is the practical signal: the code may still receive commits, but the packaged artifact has not moved in a long time. The README goes further and encourages users to look at Garnet, describing it as evolving FASTER into a full-fledged remote cache-store with throughput, latency, scalability, storage and recovery, and naming Tsavorite as a highly optimized and evolved fork of FASTER. For a new project this is a direct recommendation to consider the successor. For an existing system already built on Microsoft.FASTER.Core, the notice is a signal to plan rather than a reason to panic, because the package still exists and the source is still readable.

Where FASTER is the wrong tool

FASTER is an embedded library, not a server. The README calls FASTER KV a key-value store and cache, and it describes Garnet as the thing that turns this into a remote cache-store. If your requirement is a network-accessible cache that multiple services connect to over a protocol, FASTER itself is not that, and the README says so by pointing at Garnet. A second boundary is language. FASTER KV exists in C# and C++, and FASTER Log is described as a C# library. If your stack is Go, Rust, Java or Python, there is no artifact here for you, and you would be looking at a different class of system. A third boundary is operational. The README states that FASTER supports data larger than memory by using external storage, which means you own the storage layer and its failure modes. The log handles disk errors and supports checksums, but that is error detection and handling inside the library, not a managed service with replication and failover behind it.

Garnet and Tsavorite: the successor path in practice

The README names Garnet as the place to look, and the difference in approach is architectural rather than incremental. FASTER is a library you link into your process and point at storage you provide. Garnet is described as a full-fledged remote cache-store, which means it occupies the server position in the topology: clients talk to it over a network instead of calling into it in-process. Tsavorite, Garnet's storage engine, is described as a highly optimized and evolved fork of FASTER, so the log and index ideas carry forward rather than being discarded. The practical consequence is that a team choosing between them is really choosing a deployment shape. If your latency budget and architecture allow an in-process store and you want to avoid a network hop, FASTER is the direct fit. If you want a shared cache-store that several applications reach over the wire, the README's own recommendation points to Garnet, and starting on FASTER first would mean a migration later.

Licence, upgrade cost and what the repository does not promise

FASTER is MIT licensed, which is permissive and places few obligations on how you redistribute or modify it. That is a fact about the licence file, not legal advice, and anyone with specific compliance questions should read LICENSE and consult their own counsel. The upgrade cost is the more interesting question. The most recent release listed is v2.6.5 from 2024-05-07, and the README states the repository is no longer actively maintained. That combination means you should not expect a steady stream of fixes to land in the package. Pinning to a known version and vendoring or forking if you need changes is a more realistic plan than waiting for an upstream release. The repository does include SECURITY.md and CONTRIBUTING.md, and contributions require a Contributor License Agreement, so the project is not frozen in the sense that patches are unwelcome. It is frozen in the sense that nobody has promised to review them on a schedule.

Editorial conclusion

FASTER is worth adopting when you need an in-process, concurrent, recoverable log or key-value store in C# and can pin to the published NuGet package, and when you accept that the repository is no longer actively maintained. It is the wrong choice if you need an actively developed project or a remote cache-store, in which case the README points to Garnet and its Tsavorite storage engine. Before committing, verify the current state of the Microsoft.FASTER.Core package on NuGet, check the C# and C++ directories for the API surface you need, and confirm the checkpoint and recovery behaviour matches your durability requirements.

Frequently asked questions

Official sources

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