Redis 8.6: What Changed in Performance and Event Streams

Originally published on DevToolHub.

Redis 8.6 went GA in February 2026 and the latest patch, 8.6.7, shipped September 17 with security fixes only — the feature set has been stable for months. The headline feature isn't a speed number. It's a real fix for a problem every Streams-as-a-queue user has hit: what happens when your producer times out waiting for an XADD reply and doesn't know if the message landed. Here's Redis 8.6 explained with the commands that actually change how you'd build on it, verified against Redis's own release notes and idempotency docs.

Redis 8.6 Stream Idempotency: What XADD IDMP Actually Fixes

If you've built a queue on Redis Streams, you've hit this: a producer calls XADD, the connection drops before the reply arrives, and the producer has no way to know whether the message was written. Retry, and you risk a duplicate. Don't retry, and you risk losing the message. Per Redis's own docs, this is exactly the gap Redis 8.6 closes with idempotent message processing, new in this release.

Two modes, both added to XADD:

# Manual mode — you supply both producer ID and message ID
XADD mystream IDMP producer-1 iid-1 * field value

# Automatic mode — Redis derives the message ID from the field/value content
XADD mystream IDMPAUTO producer-1 * field value

Resend the exact same (producer-id, iid) pair — whether because the producer retried after a timeout or crashed and restarted — and Redis returns the ID of the original entry instead of writing a duplicate. IDMPAUTO skips supplying your own ID and lets Redis hash the field/value pairs instead, so identical content gets deduplicated automatically; the tradeoff is the hash calculation, which Redis's own docs note makes IDMPAUTO "slightly slower" than manual IDMP.

Retention is tunable per stream via XCFGSET:

XCFGSET mystream IDMP-DURATION 300 IDMP-MAXSIZE 1000

IDMP-DURATION (1–86,400 seconds, default 100) controls how long Redis remembers an ID; IDMP-MAXSIZE (1–10,000, default 100) caps how many IDs it tracks per producer, and is the harder limit of the two — Redis evicts the oldest tracked IDs once IDMP-MAXSIZE is hit, regardless of how much time is left on IDMP-DURATION. Redis's own sizing guidance: set IDMP-DURATION to roughly how long your producer takes to recover from a crash and resume sending, and size IDMP-MAXSIZE as mark-delay (ms) × messages/ms + margin — their own worked example is 1K msgs/sec at an 80ms mark-delay needing IDMP-MAXSIZE around 100.

This isn't free, and Redis is specific about the cost: 2–5% lower throughput on XADD compared to the non-idempotent path, with under 1.5% additional memory overhead. For a queue where a duplicate message means double-charging a customer or double-sending a notification, that's a cheap trade. For a high-throughput logging stream where an occasional duplicate is harmless, it's not worth turning on. XINFO STREAM now reports iids-duplicates so you can actually measure how often it's catching something, rather than guessing.

One real caveat from the release notes, not a hypothetical: avoid IDMP/IDMPAUTO if you're running appendonly yes with the non-default aof-use-rdb-preamble no — Redis flags this combination as a known limitation to be fixed in a later patch.

New Eviction Policies: volatile-lrm and allkeys-lrm

Redis 8.6 adds two eviction policies — volatile-lrm (keys with a TTL) and allkeys-lrm (any key) — that evict based on least recently modified, not least recently used. The distinction matters for read-heavy caches: standard LRU treats a read as "recently used" and protects the key from eviction, while LRM only resets the clock on a write. That means a key you read constantly but never update is exactly as evictable as one nobody's touched, which is the behavior you actually want if "modified recently" is a better proxy for relevance than "read recently" in your workload (a cached computed result, for instance, versus a hot but static config value you're not trying to protect from eviction just because it gets read a lot).

Hot Key Detection: the HOTKEYS Command

Redis 8.6 also ships a new HOTKEYS command for real-time detection and reporting of frequently accessed keys — useful for finding the one key that's skewing load on a cluster shard before it becomes an incident, rather than reconstructing it after the fact from slow-log guesswork.

Like our recent look at PostgreSQL 19, this is a release where the real-world impact comes down to one or two specific changes, not the full feature list.

What Redis Doesn't Quantify

Redis's own materials describe "substantial memory reduction for hashes and sorted sets" (from unifying field/value and score/value into single structs) and "substantial performance improvements" across more than 20 optimizations — but neither the official 8.6 release notes nor the "what's new" page attaches a specific percentage to either claim. Worth knowing if you're deciding whether to benchmark your own workload before upgrading: Redis isn't hiding a number here, there just isn't one published. The one area where Redis did publish a number is the idempotency overhead above (2–5% throughput, <1.5% memory) — because that's a cost, and costs get measured.

Should You Upgrade to Redis 8.6?

• Running Streams as a queue or event log where duplicates are costly: yes, specifically for IDMP/IDMPAUTO. This is the first Redis-native answer to a problem people have previously solved with external dedup tables.

• Read-heavy caching workload with a mix of hot-but-static and actively-updated keys: worth testing allkeys-lrm against your current allkeys-lru policy — it's a config change, not a migration.

• Running Redis via Docker Compose: a version bump is a good moment to double-check your compose file doesn't recreate the container unnecessarily on every up — unrelated to 8.6 itself, but worth catching while you're already touching the service definition.

• Running appendonly yes with aof-use-rdb-preamble no: hold off on IDMP/IDMPAUTO specifically until the known limitation is patched; the rest of 8.6 is unaffected.

• Just want the performance improvements: they're real per Redis's own notes, just not independently quantified — benchmark your own workload rather than expecting a specific percentage.

Frequently Asked Questions

Q: Does Redis 8.6 guarantee exactly-once delivery for Streams?
A: No — it guarantees at-most-once production (no duplicate entries from a retried XADD). Consumer-side processing guarantees are a separate concern handled by consumer groups and acknowledgments, which idempotent production doesn't change.

Q: What's the performance cost of enabling IDMP?
A: Per Redis's own docs: 2-5% lower XADD throughput, under 1.5% additional memory, with IDMPAUTO slightly slower than manual IDMP due to its hash calculation.

Q: Is allkeys-lrm a replacement for allkeys-lru?
A: Not a direct replacement — a different eviction signal. LRU tracks reads, LRM tracks writes. Pick LRM when "recently modified" better predicts what's still relevant in your workload than "recently accessed" does.

Q: What's the latest Redis 8.6 patch?
A: 8.6.7, released September 17, 2026 — security fixes only (an unauthenticated-cluster-bus-port issue and a few crash fixes). The feature set has been unchanged since the 8.6.0 GA in February 2026.

Quick Summary:

• Redis 8.6 (GA February 2026, latest patch 8.6.7) adds idempotent Streams production via XADD IDMP/IDMPAUTO — real duplicate-message prevention for queue-style use cases
• Cost is measured and specific: 2-5% lower XADD throughput, <1.5% extra memory; tune retention with XCFGSET's IDMP-DURATION/IDMP-MAXSIZE
• New volatile-lrm/allkeys-lrm eviction policies evict by last-modified time instead of last-accessed time
• New HOTKEYS command surfaces frequently-accessed keys in real time
• "Substantial" memory/performance gains are real per Redis's own notes but not independently quantified — benchmark your own workload

If you're running Streams as a real queue, XADD IDMP is the first Redis-native fix for the retry-duplicate problem — worth adopting even if you skip everything else in this release.