Redis memory calculator: estimate usage and instance size
Before you provision a Redis instance, know how much memory it actually needs. Enter your key count, data type, and value sizes to get an estimated memory footprint, a breakdown of overhead, and a recommended instance size, all calculated locally in your browser.
Not sure Redis is the right layer for your data in the first place? Read our caching strategies guide to see how Redis compares to CDN, browser, and in-process caching.
Enter your key count
from 1,000 to 100M, slider or type a numberPick a data type and size
String, Hash, List, Set, or Sorted SetRead the estimate
memory total, breakdown, and instance size
How RedisCalc works
Set the number of keys you expect to store, from 1,000 up to 100 million, using the slider or typing a number directly.
Choose the data type: String, Hash, List, Set, or Sorted Set. Each type has a different memory layout in Redis, so this changes the formula used.
For Hash, Set, and Sorted Set, set the average number of fields or members per key. For String, this is fixed at one value per key.
Set the average value size in bytes, either using the Small/Medium/Large presets or typing an exact number.
Toggle TTL on if your keys expire, and set what percentage of keys carry a TTL. Expiring keys carry a small additional memory cost in Redis's expires dictionary.
Read the results: total estimated memory, a breakdown of raw data vs structural overhead vs expiry metadata, any encoding warnings, a recommended instance size, and an estimated cloud cost comparison for that size.
What the output means
Estimated total memory
The full estimated used_memoryfor your dataset: every key, value, and Redis's own bookkeeping for each, plus a flat 2MB for the Redis process itself. This is the number you'd expect to see reported by redis-cli INFO memory once the dataset is fully loaded.
Raw / overhead / expiry breakdown
The total is split into three parts, shown as both byte values and percentages:
- Raw data: the actual payload bytes, your key names plus value content, with no Redis bookkeeping.
- Structural overhead: everything Redis adds to store that data: dictEntry structs, object headers, SDS headers, encoding-specific overhead, and jemalloc allocation rounding.
- Expiry metadata: the extra cost of tracking TTLs for keys that expire.
Memory overhead percentage
Structural overhead expressed as a percentage of raw data. Small values (short strings, few fields) have a much higher overhead percentage than large values, because the fixed per-key cost (about 56 bytes) is a bigger fraction of a tiny value than a large one. This is why storing thousands of 10-byte values is often less memory-efficient than batching them into fewer, larger structures.
Recommended instance size
The estimated total memory with 20% headroom added, rounded up to the nearest common instance size (256MB, 512MB, 1GB, 2GB, and so on up to 256GB). Running Redis near 100% of available memory risks evictions or OOM kills under noeviction, so the 20% buffer is intentional, not just rounding.
Encoding warnings
Shown when a Hash, Set, or Sorted Set exceeds the listpack thresholds (more than 128 entries, or any value over 64 bytes). For example, a Hash with 300 fields averaging 100 bytes each crosses both thresholds and gets stored as a hashtable instead of a listpack, roughly doubling the per-field overhead. The warning includes the exact CONFIG values involved so you can check or tune them.
Redis encoding thresholds reference
Redis automatically switches the internal encoding of a data structure once it grows past certain limits. Below those limits, collections use a compact, contiguous memory layout. Above them, Redis switches to a structure optimized for fast lookups at the cost of more memory per entry. The thresholds are identical between Redis 6 and Redis 7, only the compact encoding's name changed.
| Data type | Compact encoding (v6 / v7) | Thresholds | Large encoding |
|---|---|---|---|
| Hash | ziplist / listpack | ≤ 128 entries and ≤ 64 bytes per value | hashtable |
| Set (non-integer) | ziplist / listpack | ≤ 128 entries and ≤ 64 bytes per member | hashtable |
| Set (all integers) | intset | ≤ 512 entries (set-max-intset-entries) | hashtable |
| Sorted Set | ziplist / listpack | ≤ 128 entries and ≤ 64 bytes per member | skiplist |
| List | listpack nodes (quicklist) | per-node limits, configurable | quicklist (always) |
The relevant config directives, with their default values:
# Hash hash-max-listpack-entries 128 hash-max-listpack-value 64 # Set set-max-listpack-entries 128 set-max-listpack-value 64 set-max-intset-entries 512 # Sorted Set zset-max-listpack-entries 128 zset-max-listpack-value 64 # List (quicklist node sizing) list-max-listpack-size 128
On Redis 6.x, the same directives use the prefix ziplist instead of listpack (for example, hash-max-ziplist-entries). The numeric thresholds and behavior are otherwise the same; listpack is simply a more efficient successor format introduced as the default in Redis 7.
When to use RedisCalc
| Scenario | What to enter |
|---|---|
| Sizing a session store | Hash data type, number of expected concurrent sessions as keys, fields per key matching your session shape, TTL enabled at 100% |
| Sizing a product or API response cache | String data type, your average serialized JSON size as the value size, TTL enabled matching your cache expiry |
| Sizing a rate limiter | String or Hash, one key per rate-limited identity, small value sizes (a counter), short TTLs at 100% |
| Justifying instance cost to a manager | Your real numbers, then use the recommended instance size and cloud cost table to show the estimated monthly spend |
| Planning a migration from another cache | Estimate your current dataset's shape to compare memory footprint and cost before choosing a Redis tier |
| Deciding between String and Hash for small objects | Try both data types with the same total field count to compare overhead percentages directly |
Frequently Asked Questions
What is RedisCalc and what does it estimate?
RedisCalc is a browser-based calculator that estimates how much memory a Redis dataset will use. Enter your key count, data type (String, Hash, List, Set, or Sorted Set), average value size, and whether keys expire, and it estimates total memory, a breakdown of raw data versus structural overhead versus expiry metadata, and a recommended instance size with 20% headroom.
It also flags when a Hash, Set, or Sorted Set exceeds the listpack encoding thresholds and switches to a less memory-efficient encoding, and shows an estimated cloud cost comparison across AWS ElastiCache, Google Cloud Memorystore, and Upstash for the recommended size.
How does RedisCalc compare to AWS ElastiCache's sizing guidance?
| RedisCalc | AWS sizing guidance | |
|---|---|---|
| Vendor neutral | Yes, works for any Redis-compatible deployment | AWS-specific recommendations |
| Encoding-aware | Flags listpack/hashtable/skiplist threshold crossings | Generally not addressed |
| Memory breakdown | Raw data vs structural overhead vs expiry, with percentages | Limited |
| Cloud cost comparison | AWS, GCP, and Upstash side by side | AWS only |
| Setup required | None, runs in your browser instantly | Requires AWS account and console access |
RedisCalc is meant for early-stage sizing: before you provision anything, while you're still deciding between a managed Redis provider and self-hosting. Once you have a real workload running, your provider's monitoring (and the actual INFO memory output) will be more accurate than any estimator.
Is my data sent to DevEncyclopedia's servers?
No. RedisCalc runs entirely as client-side arithmetic in your browser. There are no network requests, no uploads, and nothing is stored or transmitted. You can disconnect from the internet after the page loads and the calculator still works.
How do I estimate memory for a session store with 500,000 sessions?
Say you're storing 500,000 user sessions as Redis Hashes, each with about 8 fields (user ID, role, last seen, cart ID, and so on) averaging 40 bytes per field value, and every session has a TTL of 30 minutes (so 100% of keys have a TTL).
Set Number of keys to 500,000, Data type to Hash, Average value size to 40, Fields per key to 8, enable TTL at 100%, and pick your Redis version. With these inputs, each session falls well within the listpack thresholds (8 fields, 40 bytes each), so it stays in the compact encoding.
RedisCalc will show the total estimated memory, the percentage that's structural overhead versus actual session data, and a recommended instance size with 20% headroom already applied, ready to compare against AWS ElastiCache, Memorystore, or Upstash pricing tiers.
Why does my hash use more memory than I expected?
This almost always means your hash has crossed the listpack (or ziplist on Redis 6) encoding thresholds: more than 128 fields, or any field/value larger than 64 bytes. Below those thresholds, Redis packs the whole hash into one compact contiguous allocation. Above them, it switches to a hashtable, where every field gets its own dictionary entry with separate pointers and per-entry overhead.
For example, a hash with 200 fields averaging 30 bytes each exceeds the 128-entry threshold and gets stored as a hashtable, roughly doubling the per-field overhead compared to the listpack encoding.
# Check your current thresholds
redis-cli CONFIG GET hash-max-listpack-entries
redis-cli CONFIG GET hash-max-listpack-value
# Defaults
hash-max-listpack-entries 128
hash-max-listpack-value 64If you control the data model, splitting very large hashes into smaller ones (for example, sharding by a hash of the field name) can keep each shard under the listpack thresholds. If that's not practical, the hashtable overhead is usually still acceptable: RedisCalc's encoding warning is informational, not necessarily a problem to fix.