Redis Memory Size Calculator

Workload profile:

Start with a cache, session store, rate-limit counter, queue ledger, JSON document, or custom profile.

Key count:

Use the expected peak logical key count after TTL churn and planned growth are considered.

Average key length:

Measure a typical key prefix plus identifier, not just the variable suffix.

bytes/key

Value type:

Choose the dominant data shape. Mixed workloads can be modeled with a weighted average value size.

Average value size:

Use measured MEMORY USAGE samples or a representative serialized payload average.

Primary shards:

Use 1 for a single primary, or the planned cluster primary shard count.

primaries

Replicas per primary:

Use 0 for no replicas, 1 for one read replica, or more for high availability plans.

replicas

Current maxmemory per primary:

Compare the recommended maxmemory target against an existing instance or node plan.

Headroom reserve: {{ formatPercent(result.headroomPct, 0) }}

Use 20-30% for production cache planning; lower values are only for tight what-if comparisons.

RSS fragmentation factor: {{ result.fragmentationRatio.toFixed(2) }}x

Use INFO memory's mem_fragmentation_ratio or allocator observations when available.

Eviction policy:

Choose the policy family currently configured or planned for this Redis database.

Check Redis sizing inputs

{{ error }}

Object overhead:

Profile presets update this value; override it from MEMORY USAGE sampling when you have real measurements.

bytes/key

Keys with TTL: {{ formatPercent(result.ttlSharePct, 0) }}

Use 100% for pure caches and less for mixed persistent/cached keyspaces.

TTL metadata:

Leave the default unless your sampled MEMORY USAGE comparison suggests a different TTL overhead.

bytes/TTL key

Growth reserve: {{ formatPercent(result.growthReservePct, 0) }}

Use this for product growth, new tenants, or delayed cache-key cleanup before the next capacity review.

Client and module overhead:

This is counted in the process budget and included before maxmemory headroom is applied.

MiB/primary

Replication/AOF buffers:

Leave room outside maxmemory for replication, persistence, and output buffer bursts.

MiB/primary

Fork/COW reserve: {{ formatPercent(result.forkReservePct, 0) }}

Use 0 for no persistence, or a conservative reserve for RDB/AOF rewrite windows.

Display precision:

Use 1-3 decimals for capacity review notes.

Budget item	Per primary	Cluster total	Sizing note	Copy
{{ row.label }}	{{ row.perPrimary }}	{{ row.clusterTotal }}	{{ row.note }}

Plan signal	Value	Readout	Copy
{{ row.label }}	{{ row.value }}	{{ row.readout }}

Move	Estimated effect	When to use it	Copy
{{ row.move }}	{{ row.effect }}	{{ row.when }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Redis memory sizing starts with a deceptively small question: how many bytes does each stored key really cost? The value payload is only the visible part. Key names, Redis object headers, hash tables, encodings, expiration bookkeeping, allocator behavior, client buffers, replication buffers, and persistence work can all add memory pressure before a host looks full.

Small values make this easy to miss. A rate-limit counter, session token, or dedupe marker may store only a few useful bytes, yet the key prefix and per-key overhead can dominate the budget across millions of entries. Larger JSON documents and serialized responses shift the pressure back toward payload size, but they still need room for growth, fragmentation, replicas, and background operations.

The planning number that belongs in Redis is not the same as the RAM number that belongs on the instance or container. maxmemory is the dataset limit Redis checks when it decides whether to accept writes, evict keys, or return an error. Host RAM must also cover resident set size (RSS), replica copies, client output buffers, append-only file (AOF) rewrite work, fork copy-on-write pages, and any managed-service reservation outside the modeled keyspace.

Logical dataset: The modeled keyspace: value payloads, key names, per-key object overhead, and TTL metadata.
Headroom: Spare capacity inside maxmemory for bursts, measurement error, eviction lag, and planned growth.
RSS: The memory the operating system reports for the Redis process, including allocator and process overhead beyond simple used-memory counters.
Process copies: Primaries plus replicas. Each copy needs its own process budget even when the logical keyspace is sharded.

Redis memory envelope diagram showing payload, key names, object overhead, TTL metadata, maxmemory headroom, buffers, fork reserve, and RSS margin

Eviction policy changes the failure mode. An all-keys cache can shed entries and lose hit rate. A volatile policy can evict only keys with an expiration, which means persistent coordination keys can still block growth. With noeviction, Redis does not create space for new writes when the primary reaches its limit.

A good memory plan therefore combines arithmetic with measurement. Sample representative keys with MEMORY USAGE, compare load tests with INFO memory, and keep separate reserves for traffic spikes, failover, persistence settings, and provider-specific overhead.

How to Use This Tool:

Use the calculator as a first-pass Redis sizing model before choosing nodes, shard counts, or a managed-cache plan. Start with a workload profile, then replace defaults with measurements from staging or production when you have them.

Pick the nearest workload profile: API response cache, session store, rate-limit counters, job dedupe ledger, JSON document cache, or custom.
Enter the expected peak key count, average key length, value type, average value size, primary shard count, replica count, and any current per-primary maxmemory limit you want to test.
Set headroom reserve, RSS fragmentation factor, and eviction policy. These values decide whether the result reads as a fit, thin reserve, eviction pressure, or write risk.
Open Advanced when measured overhead is available for object bytes, TTL coverage, TTL metadata, growth reserve, client/module memory, replication or AOF buffers, fork/COW reserve, or display precision.
If the summary reports Needs input, fix the invalid field before reading the tables. If it reports eviction or write risk, compare shard count, memory increase, and optimization rows before accepting the current limit.
Use Memory Budget, Shard Plan, Optimization Ledger, Memory Envelope, and JSON to review the estimate as tables, chart data, and exportable output.

Interpreting Results:

Recommended maxmemory per primary is the Redis dataset limit to compare with one primary shard. It includes the modeled keyspace, client/module overhead, growth reserve, and the selected headroom target. Do not use this value as the whole host RAM requirement.

Host RAM per Redis process adds replication or AOF buffers, fork/COW reserve, and the RSS planning factor. Use it when checking instance size, container memory limits, and how many Redis processes can share a node.

Cluster RAM for copies multiplies the process budget by primary shards and replica copies. Replicas can improve availability and read capacity, but each replica still needs memory for its full copy of the shard data.

Fits current limit means the recommended target is within the entered per-primary limit. Thin headroom means counted bytes may fit but selected growth and headroom do not. Eviction-risk or Write-risk means the modeled use already exceeds the current limit before reserve is protected.

Optimization rows are planning levers. Key shortening, hash packing, compression, sharding, resizing, and policy review should be checked against real access patterns, CPU cost, latency, and retention rules before changing production data layout.

Technical Details:

Redis memory accounting separates logical data from process memory. used_memory reports Redis allocations, while used_memory_rss reflects what the operating system sees resident in memory. Those values can diverge when allocator pages remain resident, fragmentation grows, persistence work forks a child process, or buffers accumulate outside the core dataset.

The formula starts with a logical keyspace, spreads it across primary shards, and adds growth reserve plus headroom to produce a per-primary maxmemory target. Host RAM is modeled after that because replication buffers, AOF rewrite buffers, fork copy-on-write pages, and RSS margin can sit outside the amount Redis compares with maxmemory during eviction checks.

Formula Core:

\begin{array}{lcl} B_{logical} & = & K \times (B_{value} + B_{key} + B_{object} + t \times B_{ttl}) \\ B_{per-primary} & = & \frac{B_{logical}}{primary shards} \\ B_{counted} & = & B_{per-primary} + B_{client/module} \\ B_{with-growth} & = & B_{counted} \times (1 + g) \\ recommended maxmemory & = & \frac{B_{with-growth}}{1 - h} \end{array}

\begin{array}{lcl} pre-RSS host bytes & = & maxmemory + replication/AOF buffers + fork reserve \\ host RAM per process & = & pre-RSS host bytes \times fragmentation factor \\ cluster RAM & = & host RAM per process \times primary shards \times (1 + replicas per primary) \end{array}

Redis memory sizing inputs and meaning
Input	Modeled role	Operational check
Average value size	Main payload estimate per key.	Sample real keys by type, not just serialized object expectations.
Key length	Adds key-name bytes across the full key count.	Long prefixes can become material at millions of keys.
Object overhead	Approximates Redis object, allocator, and data-structure cost per key.	Different data types and encodings have different overhead.
TTL metadata	Adds bytes for keys with expiry metadata.	Volatile-only eviction policies depend on TTL coverage.
Fragmentation factor	Moves process planning from logical bytes toward RSS.	Compare with `used_memory_rss` and fragmentation metrics in production.

Redis sizing status logic
Condition	Meaning	Typical response
Counted use exceeds current `maxmemory`	The planned dataset and counted overhead are already too large before reserve.	Raise per-primary memory, increase shard count, or reduce stored bytes.
Recommended target exceeds current `maxmemory`	The data may fit, but the selected growth and headroom reserve does not.	Decide whether the reserve is too conservative or the node plan is too small.
Volatile policy with low TTL coverage	Only expiring keys are eviction candidates, so persistent keys can still block writes.	Review TTL coverage or split persistent and disposable data into separate databases.
Replicas or persistence enabled	Extra process memory can be needed outside the dataset limit.	Leave host RAM for buffers, rewrites, fork/COW pages, and failover bursts.

Worked substitution: 2 million keys averaging 42 key bytes and 1.5 KiB values create about 3.38 GB of logical dataset after object and TTL overhead assumptions. With two primaries, 30% growth reserve, and 25% headroom, recommended maxmemory is about 2.89 GiB per primary. After buffers, fork reserve, and a 1.25x RSS factor, host RAM is about 4.49 GiB per Redis process.

Accuracy and Privacy Notes:

The calculation uses values entered in the browser and does not connect to a Redis server. It cannot inspect live encodings, module indexes, provider reservations, failover behavior, or key outliers.
Measure representative keys with MEMORY USAGE when possible. Raw value size can understate stored memory for hashes, JSON documents, sets, lists, sorted sets, and allocator overhead.
Compare load tests with INFO memory fields such as used_memory, used_memory_rss, maxmemory, mem_not_counted_for_evict, and fragmentation signals.
Replicas, persistence rewrites, client-output buffers, pub/sub, modules, scripts, and failover events can raise memory pressure outside steady-state cache data.
Eviction policy changes the operational risk. allkeys-lru can discard cache entries, volatile policies depend on TTL coverage, and noeviction can return write errors when the limit is reached.
Managed Redis offerings may add provider-specific limits, reserved memory, shard layouts, and failover overhead. Check provider documentation before procurement.

Worked Examples:

API response cache. A cache with 2 million keys, 1.5 KiB average values, two primaries, one replica, 30% growth, and 25% headroom can fit the per-primary maxmemory target while still needing far more total RAM after replicas, buffers, fork reserve, and RSS margin are counted.

Session store with volatile eviction. Session data usually expires, but a mixed Redis database can still hold persistent coordination keys. If TTL coverage drops below 100%, volatile eviction policies have fewer keys to remove and write pressure can appear sooner than expected.

Rate-limit counters. Tiny counter values make key names and per-key overhead the main memory cost. Shorter prefixes, packed counters, or more primary shards may matter more than compression because the payload is already small.

JSON document cache. Larger values and module overhead move the plan toward payload pressure. Sampling a representative document with Redis memory commands is more reliable than assuming raw JSON byte length equals stored memory.

FAQ:

Why is host RAM larger than maxmemory?

maxmemory controls dataset growth and eviction behavior, but Redis still needs memory for buffers, replication, persistence work, clients, allocator overhead, and RSS fragmentation.

Should I size from average or p95 value size?

Use representative sampling and consider p95 or per-class sizing when value sizes vary widely. A simple average can hide a small number of very large keys.

Does adding replicas reduce memory per primary?

No. Replicas add process copies for availability and read serving. They increase total cluster RAM even though each primary shard's dataset is unchanged.

Can eviction solve a bad memory estimate?

Eviction can protect cache workloads from unlimited growth, but it can also reduce hit rate or remove important entries. For non-cache data, eviction may be unacceptable.

Why do sampled keys still differ from production memory?

Samples may miss large outliers, encoding changes, module indexes, allocator behavior, client buffers, persistence windows, or provider overhead. Use them to improve the estimate, then verify with load tests and live memory metrics.

Glossary:

maxmemory: The Redis memory limit used with eviction policy to control dataset growth.
RSS: Resident set size, or the memory the operating system sees the Redis process using.
Fragmentation: The gap between allocated logical memory and resident process memory caused by allocator and memory-page behavior.
TTL metadata: Additional bookkeeping for keys that expire.
Copy-on-write reserve: RAM reserved for memory pages that can be copied during forked persistence or rewrite work.

References:

Key Eviction, Redis documentation.
MEMORY USAGE, Redis command reference.
INFO, Redis command reference.
Redis Persistence, Redis documentation.
Memory Optimization, Redis documentation.