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 begins with dataset bytes but cannot stop there. Key names, values, Redis object overhead, TTL metadata, growth reserve, eviction headroom, client buffers, replication buffers, persistence work, fork copy-on-write exposure, and RSS fragmentation all compete for RAM.

maxmemory controls how much memory Redis should use for the dataset and cache policy, while the host still needs RAM outside that limit. A cache that fits logically can still run into write errors, eviction churn, replica lag, or process memory pressure when these surrounding reserves are ignored.

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

The result is a planning estimate for capacity, shard count, and host RAM. Production sizing should be checked with representative keys, MEMORY USAGE, INFO memory, traffic peaks, failover behavior, persistence settings, and cloud-provider limits.

How to Use This Tool:

Choose a workload profile such as API cache, sessions, counters, JSON documents, dedupe ledger, or custom. Profiles provide starting values for object overhead and growth assumptions.
Enter key count, average key length, value type, average value size, primary shard count, replica count, and current maxmemory per primary.
Set eviction headroom, RSS fragmentation factor, and eviction policy. noeviction and volatile-only policies need different risk interpretation than all-keys cache policies.
Use advanced fields for per-key overhead, TTL share, TTL metadata bytes, growth reserve, client or module overhead, replication or AOF buffers, and fork copy-on-write reserve.
Check Memory Budget for dataset math, Shard Plan for per-primary fit, Optimization Ledger for levers, and the memory envelope chart for where RAM is being spent.
Export CSV, DOCX, chart images, or JSON when the estimate needs to be reviewed with application, SRE, or platform teams.

Interpreting Results:

Logical dataset includes value payload, key names, object overhead, and TTL metadata. This is closer to what Redis must represent than value bytes alone.

Recommended maxmemory per primary adds growth reserve and eviction headroom to the counted dataset and per-primary overhead. For cache workloads, the headroom helps reduce constant eviction pressure; for noeviction workloads, it reduces write-error risk.

Host RAM per Redis process adds buffers, fork reserve, and fragmentation on top of maxmemory. This value is the host-planning number, not the Redis dataset limit.

Minimum shards for current limit estimates how many primaries would keep the recommendation under the entered current limit. Replica copies multiply total cluster RAM because each replica holds its own process memory.

Technical Details:

The model calculates total logical bytes first, divides them across primary shards, then adds growth, headroom, and process reserves. It separates maxmemory sizing from host RAM because Redis can require memory outside the dataset limit for clients, replication, AOF or persistence work, and allocator/RSS behavior.

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.

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, growth reserve, and 25% headroom, recommended maxmemory is about 2.89 GiB per primary; with buffers, fork reserve, and fragmentation, host RAM is about 4.49 GiB per Redis process.

Accuracy Notes:

Measure representative keys with MEMORY USAGE when possible. Value size alone can understate stored memory for hashes, JSON documents, sets, lists, sorted sets, and allocator overhead.
Watch INFO memory fields such as used_memory, used_memory_rss, and fragmentation metrics after load tests.
Replicas, persistence rewrites, client-output buffers, pub/sub, modules, and failover events can raise memory pressure outside steady-state cache data.
Eviction policy changes the risk. allkeys-lru can discard cache entries; noeviction can return write errors when the limit is reached.
Cloud Redis offerings may add provider-specific limits, reserved memory, shard layouts, and failover overhead. Check provider documentation before procurement.

Worked Examples:

API response cache. With 2 million keys, 1.5 KiB average values, two primaries, one replica, 30% growth, and 25% headroom, the recommended maxmemory per primary is far below an 8 GiB current limit, while total process RAM across primaries and replicas is still much higher than dataset bytes.

Session store with noeviction. If counted data plus growth approaches the current limit, noeviction changes the concern from cache churn to write failures. Increase shard count, reduce payload, shorten retention, or raise the limit before load reaches that point.

JSON document cache. Larger values and module overhead can move the plan from key-count pressure to 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 limits dataset 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 reads. 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.

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.