Trimming and Memory Management

Streams grow until you trim them

Because reading does not remove entries, streams grow forever unless you trim them, and Redis memory is finite. Trim on write with XADD ... MAXLEN ~ 100000 (keep about the last 100,000 entries) or MINID ~ <id> (drop entries older than an ID, which is effectively a time cutoff), or trim separately with XTRIM. The ~ modifier allows approximate trimming: Redis removes whole internal nodes only, keeping slightly more entries than requested, which is far cheaper than exact trimming and is the recommended default. XDEL removes specific entries by ID, but it only marks them deleted inside nodes, so memory is reclaimed later; use it sparingly. Choose retention by need: enough history for consumers to recover from outages (for example, a day's worth), not unlimited. Monitor stream length and memory, and remember that trimming does not care whether consumer groups have processed the entries, so trimming too aggressively can drop unprocessed work.

Capping streams by length and age

Approximate trimming on every write keeps memory bounded cheaply.

# keep roughly the latest 100k entries
XADD orders MAXLEN '~' 100000 '*' orderId o-1003 status placed

# drop entries older than 24 hours (MINID uses the ms part of the ID)
# cutoff = now_ms - 86_400_000, computed by the client
XTRIM orders MINID '~' 1727856312345

# inspect size and memory
XLEN orders
MEMORY USAGE orders
XINFO STREAM orders

Never trim below your slowest consumer

If a consumer group is two hours behind and you keep one hour of history, those unread entries are gone. Alert on group lag and size retention to cover realistic outages.

Quick check: What does the `~` in `XADD orders MAXLEN ~ 100000 * ...` do?

• Allows approximate, cheaper trimming that may keep slightly more entries
• Makes trimming exact to the last entry
• Disables trimming
• Deletes the whole stream