Redis Memory Calculator
Data Structures
Per-Structure Breakdown
| Type↕ | Keys↕ | Raw Data↕ | Overhead↕ | Total↕ | Per Key↕ |
|---|---|---|---|---|---|
| String | 100,000 | 13.7 MB | 13.0 MB | 26.7 MB | 280 B |
Instance Details
Estimating Redis memory from raw data size alone undercounts badly, because every key carries overhead from dictionary entries, redisObject headers, SDS string allocations, and jemalloc size-class rounding. This calculator models those internal structures per data type — strings, hashes, lists, sets, and sorted sets — including the compact ziplist encoding for small collections, adds a fragmentation allowance, and recommends an ElastiCache instance with a monthly cost estimate.
Formula
Per-key (string) ≈ key+value data + dictEntry(64) + robj(16) + bucket(8) + SDS(key) + SDS(value)
- dictEntry
- Hash-table entry holding key, value, and next pointers — about 64 bytes with jemalloc
- robj
- redisObject header (type, encoding, LRU, refcount, pointer) — 16 bytes
- SDS
- Simple Dynamic String allocation: 9-byte header + data + null terminator, rounded to a jemalloc size class
- fragmentation
- Multiplier (1.1) applied to total memory to account for allocator fragmentation
How it works
- Define one or more data structures. For each, pick the type and enter the key count, average key length, average value size, and (for collections) the average fields or elements per key.
- The engine computes raw data bytes plus per-key overhead: a dictEntry (~64 B), a redisObject header (16 B), a hash-table bucket (8 B), and jemalloc-aligned SDS allocations for the key and value. Small collections use the leaner ziplist encoding instead of a full hash table.
- It sums total memory across all structures, multiplies by a 1.1 fragmentation factor, then recommends the smallest instance with roughly 20% headroom beyond the fragmented total and shows its monthly cost.
Worked example
1,000,000 string keys with an average 20-byte key and a 100-byte value.
- Raw data per key = 20 + 100 = 120 bytes → about 114.4 MB raw across 1M keys.
- Overhead per key adds dictEntry 64 + robj 16 + bucket 8 plus jemalloc-aligned SDS for the 20-byte key and 100-byte value.
- Total per key ≈ 232 bytes → about 221.3 MB total before fragmentation.
- With the 1.1 fragmentation factor → about 243.4 MB.
Roughly 221 MB of dataset memory (about 243 MB with fragmentation), comfortably fitting a cache.t3.micro (0.5 GB) at about $12/month.
Frequently asked questions
- Why is Redis memory usage higher than my raw data size?
- Each key carries fixed metadata: a dictionary entry, a redisObject header, a hash-table bucket pointer, and string headers, all rounded up to jemalloc size classes. For small values this overhead can exceed the data itself, so a 120-byte string key can consume well over 200 bytes in practice.
- What is a ziplist and why does it save memory?
- Small hashes, lists, sets, and sorted sets are stored as a compact ziplist (a contiguous byte array) instead of a full hash table or skiplist. This calculator switches to ziplist encoding when a collection stays under 128 entries and each value is 64 bytes or smaller, which dramatically reduces per-element overhead.
- Should I size my instance to exactly the calculated memory?
- No. You need headroom for fragmentation, replication buffers, client connections, and traffic spikes. The instance recommendation here targets the fragmented total plus about 20% extra, but production systems often plan for 25% or more free memory.
- Are the cost estimates accurate for my region?
- They are approximate on-demand ElastiCache prices and vary by region, reservation, and node generation. Use them to compare instance tiers rather than as an exact bill, and confirm current pricing in your cloud provider's console.