vskeyv.
A Multi-Backend Store vs an In-Process Cache
at a glance.
Compare Keyv and @humanspeak/memory-cache: a pluggable async key-value layer spanning Redis, SQLite, and Postgres against a synchronous zero-dependency in-process cache with LRU eviction and method memoization.
side-by-side.
Every surface that matters, compared without spin.
| feature | @humanspeak/memory-cache | Keyv |
|---|---|---|
| Zero Dependencies Keyv keeps its core small, but ships with serialization dependencies and each backend needs its own adapter package. | yes | no |
| TypeScript Support | Written in TypeScript | Written in TypeScript |
| Synchronous API Keyv is Promise-based everywhere so the same code can back onto Redis or SQLite. For purely in-process caching that indirection is overhead. | Sync get/set — no await on the hot path | no |
| Persistent / Shared Backends This is Keyv’s core value proposition — Memory Cache is in-process by design and does not try to compete here. | no | Redis, SQLite, Postgres, Mongo, etcd, … |
| TTL Expiration | Per cache instance | Per-entry ttl argument on set() |
| LRU Eviction Keyv’s default in-memory Map never evicts; bounded behavior requires bringing an LRU-capable store yourself. | yes | Store-dependent |
| Wildcard / Prefix Deletion | deleteByMagicString + deleteByPrefix | clear() per namespace |
| Method Memoization Decorator | @cached, async-aware | no |
| Async Fetch De-Duplication | getOrSet() collapses concurrent lookups | no |
| Built-In Statistics | getStats() aggregate counters | no |
| Namespaces | Key prefixes + prefix deletion | First-class namespaces |
| Value Compression | no | @keyv/compress-brotli / gzip adapters |
where each shines.
- +Zero runtime dependencies — works in Node and the browser
- +TypeScript-first with fully typed generics (MemoryCache<T>)
- +TTL expiration and true LRU eviction in one cache — expired entries are pruned before any valid key is evicted
- +Wildcard + prefix bulk invalidation (deleteByMagicString, deleteByPrefix)
- +@cached decorator for method-level memoization — async-aware with in-flight de-duplication
- +getOrSet() async fetch helper that de-duplicates concurrent lookups for the same key
- +Lifecycle hooks (onHit, onMiss, onSet, onDelete, onExpire, onEvict) plus built-in getStats()
- +Synchronous reads and writes — no await on the hot path
- +Swap storage backends (memory to Redis to SQLite) without changing call sites
- +Persistence and cross-process sharing when you outgrow one process
- +Per-entry TTL on every set() plus first-class namespaces
- +Actively maintained with a broad, well-documented adapter ecosystem
where each falls short.
- −Smaller community (newer project)
- −In-process only — no persistence or multi-process sharing by design
- −TTL is configured per cache instance, not per entry
- −Async API adds Promise overhead to purely in-process caching
- −Default memory store is an unbounded Map — no eviction policy built in
- −Values are serialized by default, a cost Memory Cache never pays in-process
- −No memoization decorator, fetch de-duplication, or cache statistics
the honest call.
Keyv and Memory Cache solve different problems. Keyv is a storage abstraction: reach for it when cached state must survive restarts or be shared across processes, and you want Redis today with SQLite tomorrow. Memory Cache is a cache: bounded memory, LRU + TTL, synchronous hot-path reads, memoization, and stats, all inside one process. If you are using Keyv’s default memory store just to cache computed values, Memory Cache does that job with less ceremony and real eviction.
read more.
Every head-to-head, with the same matrix + pros / cons + verdict format.
memory cache → install in 30 seconds