Feb 12, 2026

Last updated on Apr 14, 2026

Redis Big Keys: Why `--bigkeys` and `--memkeys` Should Be Used Together

Redis big key incidents get confusing when you look only at a memory graph. In production, keys with too many elements, keys that use too much memory, and keys that are both can cause different kinds of damage. That is why the first useful step is not “delete the biggest key” but “separate what is truly expensive.”

The short version is simple: --bigkeys helps you find keys with high cardinality and operational complexity, while --memkeys and MEMORY USAGE help you find keys that are truly expensive in RAM. You usually need both views to explain the data-shape problem correctly.

When this guide is the right fit

Start here if one of these sounds familiar:

Redis memory usage keeps rising and you do not know which keys matter
some commands are slow and persistence or replication cost is also growing
a few keys look suspiciously expensive, but you are not sure whether the issue is cardinality or memory
cleanup helps briefly, then the same incident returns

`bigkeys` and `memkeys` are not the same thing

According to the Redis CLI docs, redis-cli --bigkeys is about finding keys with many elements, while redis-cli --memkeys is about finding keys that consume a lot of memory.

That distinction matters in practice:

What you run	What it mostly tells you	What it can miss
`--bigkeys`	key length, cardinality, structural complexity	memory-heavy keys with modest element counts
`--memkeys`	keys that are expensive in memory	whether the operational pain comes from cardinality
`MEMORY USAGE key`	actual memory cost for one key	whole-keyspace distribution

In other words, a list, set, hash, or zset can be expensive because it has too many elements, because it is memory-heavy, or both.

What to check in the first 10 minutes

These commands are enough for the early branch:

redis-cli --bigkeys
redis-cli --memkeys
redis-cli --keystats
redis-cli MEMORY USAGE my:key SAMPLES 0

If you want to reduce scan pressure in production, the Redis CLI docs also show using -i 0.1 to sleep briefly between batches:

redis-cli --bigkeys -i 0.1
redis-cli --memkeys -i 0.1

At this stage, answer only three questions:

do I have keys with extreme cardinality?
do I have keys with extreme memory cost?
are the problematic keys concentrated in one prefix or feature area?

Why big keys are more than a memory problem

Redis latency docs make an important point: one slow command can block the single-threaded server long enough to affect other clients too. Big keys make those slow commands more likely.

Typical fallout includes:

commands touching the key take longer
replication and persistence become heavier
eviction pressure becomes harsher
one hot key distorts overall latency

That is why big keys are often a command-shape problem as much as a memory problem.

Patterns that should make you suspect big keys

These combinations show up often:

wide reads such as HGETALL, LRANGE, SMEMBERS, or ZRANGE are slow
SLOWLOG keeps showing commands touching one key family
AOF rewrite or RDB save feels especially painful
memory is high and the same key family regrows after cleanup

That usually means the incident is being recreated by data shape, not by a one-time anomaly.

Use `MEMORY USAGE` with sampling in mind

Redis docs note that MEMORY USAGE supports the SAMPLES option for nested types, with a default sample count of 5. If you want a fuller estimate, SAMPLES 0 inspects the full structure.

redis-cli MEMORY USAGE cart:123 SAMPLES 0
redis-cli MEMORY USAGE timeline:user:42 SAMPLES 0

That is especially useful when the question is “why is this key so expensive even though the element count does not look outrageous?”

Common wrong starts

These are common, but usually poor first moves:

using KEYS * to inspect the whole dataset
assuming --bigkeys alone explains memory behavior
deleting the largest key immediately
assuming maxmemory alone is the fix

The Redis latency docs specifically warn about KEYS as a common source of production latency, so it is worth avoiding as the default move.

A practical debugging order

1. Run both `--bigkeys` and `--memkeys`

Separate cardinality pain from memory pain first.

2. Use `--keystats` or `MEMORY USAGE` to measure the real weight

Move from guesswork to actual key cost.

3. Identify the command families touching those keys

SLOWLOG and app traces usually help here.

4. Revisit retention, sharding boundaries, and object shape

Long-term fixes are usually shape changes, not cleanup scripts.

5. Re-check persistence and latency side effects

A memory graph looking better does not mean the whole incident is over.

Patterns that usually require structural change

Redesign becomes more likely when:

one key holds data for an entire tenant
one time window keeps growing too long
every read touches too much data
Redis is storing a materialized blob it should not be storing

Common structural moves include:

splitting by tenant, date, or object boundary
enforcing shorter retention
separating summary data from raw data
moving the workload to a better-fitting storage shape

Checklist

I compared --bigkeys and --memkeys
I sampled real key cost with MEMORY USAGE ... SAMPLES 0
I know which command families touch the problematic key family
I reviewed whether retention or key boundaries should change
I re-checked persistence and latency impact, not only memory

FAQ

Q. Is a big key only a memory problem?

No. It often affects memory, latency, persistence, and eviction behavior together.

Q. What is the fastest first step?

Run --bigkeys and --memkeys together so you can separate cardinality pain from memory pain.

Q. Should I just delete the largest key?

Only if you understand the application impact and the regrowth path. Otherwise the same pattern often comes back.

Q. When is redesign unavoidable?

When the same key family repeatedly recreates memory and latency incidents.

Start Here

Continue with the core guides that pull steady search traffic.