In-Memory Caching Strategies for Node.js Applications
lru-cache, memory-cache, node-cache, and quick-lru are all in-memory caching solutions for Node.js, but they serve different architectural needs. lru-cache is a strict Least Recently Used (LRU) implementation ideal for limiting memory usage based on access patterns. node-cache focuses on Time-To-Live (TTL) expiration with event hooks, suitable for general purpose data caching. quick-lru is a minimal, fast LRU cache without dependencies, often used in simpler contexts or browsers. memory-cache is a legacy package often found in older tutorials but lacks active maintenance. Choosing the right one depends on whether you need strict LRU eviction, TTL-based expiration, or long-term stability.
Npm Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
In-Memory Caching: lru-cache vs node-cache vs quick-lru vs memory-cache
When building Node.js applications, in-memory caching is a common strategy to reduce database load, speed up API responses, or store temporary computation results. The packages lru-cache, memory-cache, node-cache, and quick-lru all solve this problem, but they approach it differently. Some focus on strict Least Recently Used (LRU) eviction, while others prioritize Time-To-Live (TTL) expiration. Let's break down how they work and when to use each.
🧠 Core Caching Strategy: LRU vs TTL
The most important difference is how these packages decide when to remove data.
lru-cache strictly follows the Least Recently Used algorithm.
- It evicts the least accessed items when the cache reaches its max size.
- Supports TTL, but LRU is the primary mechanism.
// lru-cache: Strict LRU with optional TTL
import { LRUCache } from 'lru-cache';
const cache = new LRUCache({ max: 100, ttl: 1000 * 60 * 5 });
node-cache focuses on Time-To-Live (TTL).
- Items expire after a set time, regardless of how often they are accessed.
- Has a
maxKeysoption, but eviction is not strictly LRU.
// node-cache: TTL focused
const NodeCache = require('node-cache');
const cache = new NodeCache({ stdTTL: 300, checkperiod: 120 });
quick-lru is a simple count-based LRU.
- Evicts oldest items when max size is reached.
- Does not support TTL natively.
// quick-lru: Simple count-based LRU
import QuickLRU from 'quick-lru';
const cache = new QuickLRU({ maxSize: 100 });
memory-cache uses TTL primarily.
- Similar to
node-cachebut with fewer features. - Items expire after a defined time in milliseconds.
// memory-cache: TTL based (Legacy)
const MemoryCache = require('memory-cache');
const cache = new MemoryCache();
⚙️ Basic API Usage: Setting and Getting Data
All four packages allow you to store and retrieve values, but the method names and units differ.
lru-cache uses set and get.
- TTL is passed as an option in
setor constructor.
// lru-cache
import { LRUCache } from 'lru-cache';
const cache = new LRUCache({ max: 100 });
cache.set('key', 'value', { ttl: 5000 });
const value = cache.get('key');
node-cache uses set and get.
- TTL is in seconds by default.
// node-cache
const NodeCache = require('node-cache');
const cache = new NodeCache();
cache.set('key', 'value', 100); // 100 seconds
const value = cache.get('key');
quick-lru uses set and get.
- No TTL argument accepted.
// quick-lru
import QuickLRU from 'quick-lru';
const cache = new QuickLRU({ maxSize: 100 });
cache.set('key', 'value');
const value = cache.get('key');
memory-cache uses put and get.
- TTL is in milliseconds.
// memory-cache
const MemoryCache = require('memory-cache');
const cache = new MemoryCache();
cache.put('key', 'value', 5000); // 5000 milliseconds
const value = cache.get('key');
⏱️ Time-To-Live (TTL) Handling
Expiration logic varies significantly, especially between milliseconds and seconds.
lru-cache handles TTL in milliseconds.
- Precise control over short-lived data.
// lru-cache: TTL in ms
cache.set('session', data, { ttl: 60000 }); // 1 minute
node-cache handles TTL in seconds.
- Easier for longer durations, less precise for sub-second.
// node-cache: TTL in seconds
cache.set('session', data, 60); // 1 minute
quick-lru does not support TTL.
- Items stay until evicted by count.
// quick-lru: No TTL support
cache.set('session', data); // Stays until maxSize reached
memory-cache handles TTL in milliseconds.
- Similar to
lru-cachebut less configurable.
// memory-cache: TTL in ms
cache.put('session', data, 60000); // 1 minute
⚠️ Maintenance and Stability
This is a critical factor for production applications.
lru-cache is actively maintained.
- Regular updates, modern ESM support (v9+), widely trusted.
// lru-cache: Modern ESM import
import { LRUCache } from 'lru-cache';
node-cache is actively maintained.
- Stable, reliable, good for long-term projects.
// node-cache: CommonJS require
const NodeCache = require('node-cache');
quick-lru is actively maintained.
- Simple, low risk, maintained by Sindre Sorhus.
// quick-lru: Modern ESM import
import QuickLRU from 'quick-lru';
memory-cache is unmaintained.
- No updates since ~2017. Do not use in new projects.
// memory-cache: Legacy warning
// ⚠️ Not recommended for new development
const MemoryCache = require('memory-cache');
🌐 Real-World Scenarios
Scenario 1: API Response Caching
You need to cache API responses for 5 minutes to reduce external calls.
- ✅ Best choice:
node-cacheorlru-cache - Why? TTL is the primary requirement here.
// node-cache example
if (!cache.has(url)) {
const data = await fetch(url);
cache.set(url, data, 300); // 5 minutes
}
Scenario 2: Build Tool Optimization
You are caching file transformations in a build tool. Memory must not explode.
- ✅ Best choice:
lru-cacheorquick-lru - Why? Strict memory limits are crucial.
quick-lruis lighter.
// quick-lru example
const cache = new QuickLRU({ maxSize: 1000 });
cache.set(filePath, transformedContent);
Scenario 3: Session Storage
Temporary user sessions that must expire automatically.
- ✅ Best choice:
node-cacheorlru-cache - Why? You need reliable expiration events or TTL.
// lru-cache example
const cache = new LRUCache({ ttl: 1000 * 60 * 30 });
cache.set(userId, sessionData);
Scenario 4: Legacy Express App
Maintaining an old Express app that already uses a specific cache.
- ⚠️ Choice:
memory-cache(Only if existing) - Why? Refactoring might be risky, but plan to migrate.
// memory-cache example
// Only for legacy maintenance
cache.put('temp', value, 1000);
📊 Summary Table
| Feature | lru-cache | node-cache | quick-lru | memory-cache |
|---|---|---|---|---|
| Strategy | Strict LRU + TTL | TTL + Max Keys | Strict LRU (Count) | TTL |
| TTL Unit | Milliseconds | Seconds | None | Milliseconds |
| Maintenance | ✅ Active | ✅ Active | ✅ Active | ❌ Unmaintained |
| Dependencies | None | None | None | None |
| Module Type | ESM (v9+) | CJS/ESM | ESM | CJS |
| Events | Limited | ✅ Rich (del, expired) | None | None |
💡 Final Recommendation
For most modern Node.js applications, lru-cache is the safest and most powerful choice. It balances strict memory management with TTL support and is actively maintained. Use node-cache if you prefer TTL in seconds and need event hooks for cache misses or expirations. quick-lru is excellent for lightweight tools or browser-based caching where you just need to limit item count. Avoid memory-cache in any new project due to its lack of maintenance and potential security risks.
Choose based on whether you need time-based expiration (node-cache, lru-cache) or strict memory limits (lru-cache, quick-lru), and always prioritize actively maintained packages.
How to Choose: quick-lru vs lru-cache vs memory-cache vs node-cache
- quick-lru:
Choose
quick-lruif you need a lightweight, dependency-free LRU cache for simple use cases or browser environments. It is extremely fast and easy to set up but lacks TTL support and advanced features. Perfect for CLI tools, small utilities, or frontend build processes where you just need to limit the number of cached items by count. - lru-cache:
Choose
lru-cacheif you need a robust, strictly enforced LRU algorithm with advanced features like async fetching and size calculation. It is the industry standard for high-performance caching where memory limits must be respected based on usage frequency. Ideal for build tools, complex server-side caching, and scenarios requiring precise control over eviction. - memory-cache:
Avoid
memory-cachefor new projects as it is unmaintained and has not seen updates in years. It may still work for simple key-value storage in legacy systems, but it lacks modern features and security patches. Only use this if you are maintaining an older codebase that already depends on it and refactoring is not an option. - node-cache:
Choose
node-cacheif your primary requirement is Time-To-Live (TTL) expiration rather than strict LRU eviction. It offers useful events likedelandexpired, making it great for session storage or temporary data that must vanish after a set time. It is a solid choice for general-purpose caching where simplicity and TTL are more important than access-pattern optimization.
Popular Comparisons
README for quick-lru
quick-lru 
Useful when you need to cache something and limit memory usage.
See the algorithm section for implementation details.
Install
npm install quick-lru
Usage
import QuickLRU from 'quick-lru';
const lru = new QuickLRU({maxSize: 1000});
lru.set('🦄', '🌈');
lru.has('🦄');
//=> true
lru.get('🦄');
//=> '🌈'
API
new QuickLRU(options?)
Returns a new instance.
It's a Map subclass.
options
Type: object
maxSize
Required
Type: number
The target maximum number of items before evicting the least recently used items.
[!NOTE] This package uses an algorithm which maintains between
maxSizeand2 × maxSizeitems for performance reasons. The cache may temporarily contain up to twice the specified size due to the dual-cache design that avoids expensive delete operations.
maxAge
Type: number
Default: Infinity
The maximum number of milliseconds an item should remain in the cache.
By default, maxAge will be Infinity, which means that items will never expire.
Lazy expiration occurs upon the next write or read call.
Individual expiration of an item can be specified by the set(key, value, options) method.
onEviction
Optional
Type: (key, value) => void
Called right before an item is evicted from the cache due to LRU pressure, TTL expiration, or manual eviction via evict().
Useful for side effects or for items like object URLs that need explicit cleanup (revokeObjectURL).
[!NOTE] This callback is not called for manual removals via
delete()orclear(). It fires for automatic evictions and manual evictions viaevict().
Instance
The instance is an Iterable of [key, value] pairs so you can use it directly in a for…of loop.
Both key and value can be of any type.
.set(key, value, options?)
Set an item. Returns the instance.
Individual expiration of an item can be specified with the maxAge option. If not specified, the global maxAge value will be used in case it is specified in the constructor; otherwise, the item will never expire.
.get(key)
Get an item.
.has(key)
Check if an item exists.
.peek(key)
Get an item without marking it as recently used.
.delete(key)
Delete an item.
Returns true if the item is removed or false if the item doesn't exist.
.clear()
Delete all items.
.expiresIn(key)
Get the remaining time to live (in milliseconds) for the given item, or undefined if the item is not in the cache.
- Does not mark the item as recently used.
- Does not trigger lazy expiration or remove the entry when it’s expired.
- Returns
Infinityif the item has no expiration (maxAgenot set for the item and no globalmaxAge). - May return a negative number if the item has already expired but has not yet been lazily removed.
.resize(maxSize)
Update the maxSize, discarding items as necessary. Insertion order is mostly preserved, though this is not a strong guarantee.
Useful for on-the-fly tuning of cache sizes in live systems.
.evict(count?)
Evict the least recently used items from the cache.
The count parameter specifies how many items to evict. Defaults to 1.
It will always keep at least one item in the cache.
import QuickLRU from 'quick-lru';
const lru = new QuickLRU({maxSize: 10});
lru.set('a', 1);
lru.set('b', 2);
lru.set('c', 3);
lru.evict(2); // Evicts 'a' and 'b'
console.log(lru.has('a'));
//=> false
console.log(lru.has('c'));
//=> true
.keys()
Iterable for all the keys.
.values()
Iterable for all the values.
.entriesAscending()
Iterable for all entries, starting with the oldest (ascending in recency).
.entriesDescending()
Iterable for all entries, starting with the newest (descending in recency).
.entries()
Iterable for all entries, starting with the oldest (ascending in recency).
This method exists for Map compatibility. Prefer .entriesAscending() instead.
.forEach(callbackFunction, thisArgument)
Loop over entries calling the callbackFunction for each entry (ascending in recency).
This method exists for Map compatibility. Prefer .entriesAscending() instead.
.size (getter)
The stored item count.
.maxSize (getter)
The set max size.
.maxAge (getter)
The set max age.
Algorithm
This library implements a variant of the hashlru algorithm using JavaScript's Map for broader key type support.
How it works
The algorithm uses a dual-cache approach with two Map objects:
- New cache - Stores recently accessed items
- Old cache - Stores less recently accessed items
On set() operations:
- If the key exists in the new cache, update it
- Otherwise, add the key-value pair to the new cache
- When the new cache reaches
maxSize, promote it to become the old cache and create a fresh new cache
On get() operations:
- If the key is in the new cache, return it directly
- If the key is in the old cache, move it to the new cache (promoting its recency)
Benefits
- Performance: Avoids expensive
deleteoperations that can cause performance issues in JavaScript engines - Simplicity: No complex linked list management required
- Cache efficiency: Maintains LRU semantics while being much faster than traditional implementations
Trade-offs
- Size variance: The cache can contain between
maxSizeand2 × maxSizeitems temporarily - Memory overhead: Uses up to twice the target memory compared to strict LRU implementations
When to use
Choose this implementation when:
- You need high-performance caching with many operations
- You can tolerate temporary size variance for better performance
- You want simple, reliable caching without complex data structures
Consider alternatives when:
- You need strict memory limits (exactly
maxSizeitems) - Memory usage is more critical than performance
Related
- yocto-queue - Tiny queue data structure