VictoriaMetrics/fastcache: a Go in-memory cache built to keep GC quiet

The problem fastcache attacks: heap pointers, not lookup speed

A plain `map[string][]byte` with a billion short entries holds roughly a billion pointers. The Go garbage collector has to scan every one of them, and the usual escape hatch is tuning `GOGC`, which trades memory for scan time. fastcache was extracted from VictoriaMetrics to avoid that trade entirely. The README states that a 64GB cache would contain around 1M pointers, while a similarly sized `map[string][]byte` would contain around 1B. The intended reader is a Go engineer running a large in-process cache where the GC pause, not the map lookup, is the bottleneck. If your cache holds a few thousand entries, this project solves a problem you do not have.

Buckets, 64KB chunks, and where the pointers went

The architecture follows ideas the README credits to BigCache. The cache is split into many buckets, each with its own lock, so goroutines touching different buckets do not contend. Inside a bucket there is a `hash(key) -> (key, value) position` map plus 64KB byte slices, called chunks, that hold encoded key and value entries. The map stores positions, not the data, so a bucket holds only `O(chunksCount)` pointers. Chunks are allocated off-heap where possible, which the README says reduces total memory usage because the GC collects unused memory more often without `GOGC` tweaking. The 64KB chunk size is a deliberate middle ground: smaller chunks would mean more pointers and more bookkeeping, one large chunk per bucket would fragment more. Note that keys and values must be byte slices, so anything else has to be marshaled first.

Installing fastcache and a first real use

The module path is `github.com/VictoriaMetrics/fastcache`, and `go.mod` declares `go 1.24.0`. Add it with the standard Go toolchain:

go get github.com/VictoriaMetrics/fastcache

The README describes the API as simple and designed for zero-allocation use, and it names `Set`, `Get`, `SetBig`, `SaveToFile` and `LoadFromFile` as the surface. The Godoc link in the README is where the full signatures live, so check it before writing your first call. What the README does spell out is the shape of the work: create a cache with a maximum size in bytes, store byte-slice keys and values, and read them back. Entries larger than 64KB go through the separate `SetBig` API, which the README calls out explicitly. For persistence, the README documents `SaveToFile` and `LoadFromFile` on the `Cache` type. A practical caveat: because there is no expiration, a value you write stays until the cache overflows, so if your data has a natural lifetime you must encode a deadline inside the value and check it after reading, exactly as the README suggests.

No expiration, no callbacks, no thundering herd protection

These are stated limitations, not oversights. The README explains that VictoriaMetrics does not need expiration because cached entries there never expire and are evicted only on size overflow. The same reasoning covers missing callbacks on eviction and thundering-herd protection: the README says those features would complicate the code and make it slower, and suggests copy-pasting the source to build what you need. That is a real constraint. A cache where every key must eventually disappear, or where a miss storm against a slow backend has to be collapsed into one fetch, is the wrong tool. The project also gives no eviction ordering beyond size overflow, so you cannot reason about which entry is dropped next. If you need LRU semantics or TTLs as first-class behavior, look elsewhere and stop reading here.

How fastcache differs from BigCache and FreeCache

The README's own FAQ compares fastcache to BigCache and FreeCache on three axes: speed, memory use from lower heap fragmentation, and API simplicity. BigCache shares the bucketed lineage, and fastcache's own benchmark output shows it ahead of BigCache in the Set, Get and SetGet cases, with far fewer allocations per operation. The README also reports fastcache beating the standard Go map and `sync.Map` on insert-heavy workloads, while `sync.Map` wins the pure-read case. FreeCache is the other name the README raises. The meaningful difference is not the benchmark table, which is the maintainers' own and should be reproduced on your hardware, but the design target: fastcache keeps the API small and the source simple enough to fork. If you want a feature-rich cache with TTLs and eviction hooks handled for you, a library that ships those features is a better fit than fastcache plus your own wrapper.

Maintenance, upgrade cost and the MIT licence

The repository is not archived, and the last push was on 2026-06-15, so it is not abandoned. The most recent release listed is v1.13.0 from 2025-08-06, preceded by v1.12.5 and v1.12.4 in mid-2025. Release cadence is slow and tied to the needs of VictoriaMetrics rather than a broad user base, which fits a small library. The dependency set in `go.mod` is short: `github.com/cespare/xxhash/v2`, `github.com/golang/snappy`, `golang.org/x/sys`, and `github.com/allegro/bigcache` (used in tests), plus indirect test dependencies. Upgrading means bumping the module and re-running your own benchmarks, because the README's numbers are from the maintainers' environment. The licence is MIT, which is permissive and permits commercial use and modification; this is a factual note, not legal advice, and you should have counsel review distribution terms if your product embeds the code.

Editorial conclusion

Adopt fastcache when you are caching hundreds of thousands to hundreds of millions of small byte-slice entries in Go and the garbage collector is what hurts. Do not adopt it if you need TTLs, typed values without marshaling, callbacks, or thundering-herd protection out of the box; the README says those are deliberately absent. Before committing, check that your values fit the 64KB path, that you can live with size-overflow eviction only, and that the MIT licence terms fit your distribution.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. VictoriaMetrics/fastcache on GitHub