Redis Memory Size Calculator

{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}

Workload profile:

Choose a common workload or keep a custom set of values.

Logical key count:

Use the expected peak key count before sharding.

Key count unit:

Average key length:

Measure representative full key names.

bytes/key

Dominant value type:

Choose the closest data shape, then replace the overhead with measured MEMORY USAGE evidence.

Average value size:

Use a representative stored-value average.

Value size unit:

Measured per-key overhead:

Replace the preset with a MEMORY USAGE-derived estimate for the deployed Redis version.

bytes/key

Keys with TTL:

Enter the estimated share of expiring keys.

{{ formatNumber(ttl_share_pct, 0) }}%

TTL metadata allowance:

Estimate additional expiration bookkeeping per expiring key.

bytes/TTL key

Primary shards:

Use one for a standalone primary or the planned cluster primary count.

primaries

Replicas per primary:

Enter zero to five replica copies per primary.

replicas

Current maxmemory per primary:

Compare the recommendation with an existing node or service limit.

maxmemory unit:

Headroom inside maxmemory:

A planning policy, not a Redis default.

{{ formatNumber(headroom_pct, 0) }}%

RSS planning factor:

Use INFO memory and peak observations when available.

{{ formatNumber(fragmentation_ratio, 2) }}x

Eviction policy family:

Choose the planned Redis maxmemory-policy behavior.

Future growth allowance:

Model growth before the next sizing review.

Client and module allowance:

Use INFO memory or service-provider measurements.

MiB/process

Replication/AOF allowance:

Use mem_not_counted_for_evict and peak backlog/AOF observations.

MiB/process

Fork/COW reserve:

Use peak copy-on-write measurements from production-like persistence activity.

% of maxmemory

Display precision:

Choose one to three decimals for human-readable memory values.

Budget item	Per primary	Cluster copies	Planning meaning	Copy
{{ row.item }}	{{ row.perPrimary }}	{{ row.cluster }}	{{ row.note }}

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

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

{{ chartLoading ? 'Loading chart…' : 'Chart unavailable. Download CSV or retry.' }}

A Redis value rarely costs only its payload bytes. The key name, object representation, hash-table entry, expiration record, allocator behavior, client buffers, replication work, and persistence activity all compete for memory. With millions of short-lived counters or session keys, those less visible bytes can outweigh the stored value itself.

The planning problem has three distinct totals. Logical dataset size estimates all keys before sharding. maxmemory is a per-primary dataset limit used for eviction or write decisions. Host RAM must extend beyond that limit for resident set size (RSS), buffers, fork copy-on-write pages, and other process memory.

Redis memory planning totals
Planning total	What it answers	Main additions
Logical dataset	How large is the complete keyspace?	Values, key names, object overhead, TTL metadata
Per-primary `maxmemory`	What dataset limit should one primary use?	Shard share, client/module allowance, growth, headroom
Host RAM per process	How much memory should the process environment reserve?	Replication/AOF allowance, fork reserve, RSS factor

Average size assumptions need representative evidence. Small samples can miss long key names, rare large documents, encoding changes, module indexes, or a high percentile that dominates the total. Redis MEMORY USAGE samples help estimate per-key cost, while INFO memory shows process-wide behavior such as allocated memory and RSS under a realistic workload.

Headroom inside maxmemory and the RSS planning factor protect different boundaries. Headroom leaves unused dataset capacity for variation and growth. The RSS factor expands the process plan after explicit buffers and fork reserve. Treating either value as a universal constant can understate one workload and waste memory on another.

Eviction policy changes the consequence of an undersized limit, not the byte estimate. An all-keys cache may discard entries and lose hit rate. A volatile policy can evict only expiring keys. With noeviction, writes that need more memory can fail instead of freeing space.

Replicas multiply the process budget because every replica holds a copy of its primary shard. They improve availability or read capacity, but they do not reduce the memory required by one copy. Managed services may also reserve memory outside the modeled process budget, so provider limits still need a separate check.

How to Use This Tool:

Use a workload profile as a starting point, then replace its assumptions with measurements from the Redis version and data shape you plan to run.

Choose a Workload profile or Custom, then enter the expected peak Logical key count, average key length, value type, and average stored-value size.
Enter measured Per-key overhead, the share of keys with a TTL, and the TTL metadata allowance. Sample several representative key classes instead of relying on one convenient key.
Set Primary shards, Replicas per primary, future growth, headroom inside maxmemory, and the RSS planning factor.
Add client/module, replication/AOF, and fork reserves when production-like measurements support them, then compare the recommendation with the current per-primary maxmemory.
Review the status and shard-fit result together with Host RAM per process and total RAM for all primary and replica copies.

Interpreting Results:

Recommended maxmemory per primary is the modeled dataset limit for one primary shard. It is not the whole process or node requirement. Host RAM per process adds modeled buffers, fork reserve, and RSS margin; Total cluster RAM multiplies that process amount across primaries and replicas.

Fits current means the recommended limit is less than or equal to the entered current limit.
Thin headroom means counted use fits, but the full headroom target does not.
Eviction risk means counted use exceeds the current limit under an eviction policy.
Write risk means counted use exceeds the current limit while noeviction is selected.

Shard count to fit current limit finds the smallest primary count, up to 512, whose modeled per-primary dataset, client allowance, growth, and headroom fit the entered maxmemory. It does not prove that the shard count meets throughput, failover, slot-distribution, or operational requirements.

Technical Details:

Byte counts use binary KiB, MiB, GiB, and TiB factors. Canonical calculations retain full precision; the display precision setting changes only formatted values from one to three decimal places.

Formula Core

Let N be logical keys, v average value bytes, k average key-name bytes, o measured per-key overhead, t the fraction of keys with a time to live (TTL), and x TTL metadata bytes per expiring key. Logical dataset bytes D are:

D = N (v + k + o + t x)

For P primary shards, client/module allowance A per process, growth percentage g, and headroom percentage h, counted bytes and recommended maxmemory are:

\begin{matrix} K & = & (\frac{D}{P} + A) (1 + \frac{g}{100}) \\ M_{maxmemory} & = & \frac{K}{1 - \frac{h}{100}} \end{matrix}

Let B be the replication/AOF allowance, f the fork reserve percentage of recommended maxmemory, and r the RSS planning factor. Host RAM per process and RAM for all copies are:

\begin{matrix} H_{process} & = & (M_{maxmemory} + B + M_{maxmemory} \frac{f}{100}) r \\ H_{cluster} & = & H_{process} \times P \times (1 + R) \end{matrix}

Here R is replicas per primary. Replication/AOF and client/module allowances are entered in MiB per process. The fork reserve is a percentage of recommended maxmemory, and the RSS factor is applied after those explicit additions.

For the default API cache, two million keys with 42-byte names, 1.5 KiB values, 96 bytes of object overhead, and 16 bytes of TTL metadata on every key produce 3,380,000,000 logical bytes. Two primaries split that to 1,690,000,000 bytes each. With 25% headroom and no added growth or buffers, recommended maxmemory is about 2.10 GiB, host RAM at a 1.25× RSS factor is about 2.62 GiB per process, and two primaries with one replica each require about 10.49 GiB for all four modeled copies.

Rule Core

Status comparisons use the current per-primary maxmemory, when it is greater than zero:

Redis sizing status decision order
Condition	Status
Counted bytes > current limit and policy is `noeviction`	Write risk
Counted bytes > current limit and another policy is selected	Eviction risk
Counted bytes ≤ current limit, but recommended `maxmemory` > current limit	Thin headroom
Recommended `maxmemory` ≤ current limit	Fits current
Current limit is zero	Sizing ready; no fit comparison

Accuracy Notes:

The result is a transparent capacity estimate built from averages and user-entered reserves. Redis version, allocator, encoding thresholds, modules, persistence mode, traffic, and managed-service policy can change real memory use.

Measure representative key classes and high-percentile values; a global average can hide costly outliers.
Observe peak client buffers, replication backlog, append-only file activity, and copy-on-write memory during production-like tests.
Do not treat an eviction policy as extra capacity. Evicted cache entries reduce hit rate, and non-cache data may not be disposable.
Keep operating-system, monitoring, sidecar, and provider reservations outside the Redis process plan.

References:

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