Ristretto

Ristretto is a free, open-source Go library for keeping key-value data in process memory. It fits Go services that need a fast concurrent cache and can define the relative cost of entries. Its single-process design and non-guaranteed admission of new items make it unsuitable as a shared cache or authoritative store.

Overview

Ristretto is designed around performance and correctness for memory-bound caching. TinyLFU admission filters incoming entries while SampledLFU eviction selects items to remove, a combination intended to preserve useful data and improve hit ratios. Batching, contention management, and eventual consistency help its throughput, but they also mean cache state does not necessarily change synchronously with every call.

A call that sets a new key can be discarded while it travels through the Set buffer or admission policy; updates are guaranteed. Code that treats a successful Set as proof that a new value is immediately cached needs a separate source of truth and a read path that handles misses. The cache runs inside one process, is not distributed, and does not persist data after that process stops. The project describes it as production-ready, and Badger and Dgraph are named users. Apache License 2.0 permits use and modification under that license.

Key features

• Frequency-oriented policies: TinyLFU admission and SampledLFU eviction favor entries likely to be reused. This is a good fit for skewed workloads where retaining hot keys matters more than accepting every write, but it is not a guarantee that a newly seen key will enter.
• Application-defined cost: Your code assigns each entry a cost, allowing one valuable large object to evict several cheaper objects. That is useful when memory impact and business value differ, provided the cost function reflects the workload rather than merely counting keys.
• Concurrent goroutine access: The library is built for concurrent use with little throughput degradation attributed by the project to its design. It suits a busy Go service sharing a cache among goroutines, without implying cross-process coordination.
• Optional metrics: Throughput, hit ratio, and other statistics can be collected when needed. Metrics help tune admission, costs, and capacity, while leaving instrumentation optional for smaller deployments.
• TTL support: Entries can use time-to-live expiration, useful for data that should age out even when it remains popular. Ristretto remains an in-memory cache, so TTL does not provide persistence.
• Generics in version 2: The project recommends version 2 for new programs and supports Go generics there, making typed cache code a natural choice for current Go modules.

Pricing

There is no subscription charge, hosted allowance, seat schedule, or trial term. You supply the runtime and operations, and the cache is limited by the memory and capacity of that process rather than a vendor quota. The project requires Go 1.21 or newer and Go modules. Free access does not include a managed, distributed service or durable storage.

Platforms

Ristretto supports Linux, macOS, Windows, and self-hosted deployments through its Go API. It is a library rather than a standalone cache server, so the host application owns process lifecycle, sizing, upgrades, and monitoring. Its deployment model is single-process; applications needing several services to see the same cache should choose a networked system instead.

Who it's for

Choose Ristretto for a Go application that needs a high-throughput local key-value cache, can tolerate an occasional dropped first write, and benefits from weighting entries by application-defined cost. It is particularly compelling when hot-item retention and concurrent goroutine access matter more than immediate admission of every key.

Look elsewhere when cache contents must survive restarts, be shared between processes or hosts, or act as the system of record. Teams that do not control Go 1.21+ builds, or that want a managed endpoint rather than embedded software, will also need another approach.

Pros and cons

Pros

• Free and open source: Apache 2.0 licensing avoids a product subscription and supports self-hosted operation.
• Policies aimed at hit ratio: TinyLFU plus SampledLFU can keep frequently useful entries in a bounded memory footprint.
• Cost-aware capacity: Application-defined costs handle uneven object sizes better than a key-count-only policy.
• Concurrency and visibility: Goroutine-safe access and optional hit-ratio and throughput metrics support busy services and tuning.

Cons

• New-item Sets may be dropped: A first write can be rejected by buffering or admission, so callers must handle misses and cannot assume immediate caching.
• Single-process only: Separate instances do not share entries, ruling it out for a common cache across service replicas.
• No persistence: Restarting the process loses cached data, and TTL cannot change that durability boundary.
• Operational ownership: Self-hosting leaves capacity, upgrades, and runtime management to your team.

Alternatives

For a broader comparison of cache products, see Caching Software. If your priority is a database-style key-value service rather than an embedded cache, browse Key-Value Databases or Embedded Databases.

• Amazon ElastiCache is the better choice when you want a hosted, network-accessible cache and can use AWS pricing, including its free-tier credits.
• Aiven for Valkey suits teams seeking a managed service, with a free tier offering one dedicated VM, one CPU, and 1 GB of RAM.
• Garnet is an alternative for self-hosted or Azure Cosmos DB cache deployments rather than an embedded Go library.
• Memcached is a straightforward free, self-hosted cache when you prefer a standalone service and protocol.
• Squid is aimed at proxy caching, not in-process Go key-value caching.
• Apache Traffic Server is a free self-hosted traffic-cache option for API or server deployments.
• cache2k is a free Apache-licensed Java caching library, making it the natural alternative for Java applications.
• Accessibility Test Framework for Android is an Android testing project, not a cache replacement.

Verdict

Ristretto is a strong choice for Go developers embedding a bounded, concurrent cache where hit ratio and cost-aware eviction are priorities. Pick it for fast local acceleration under your control; choose a distributed or persistent service instead if every write must be visible across processes or survive a restart.