Last checked and updated on April 20, 2026What Is New in Redis 4.0
Redis 4.0 is a major release focused on extensibility, operational resilience, and memory efficiency. It introduces a game-changing module system, a more robust replication protocol, and several new commands for better database management.
| Category | Key Changes |
|---|---|
| New Features | Redis Modules, PSYNC2 replication, Mixed RDB+AOF persistence, new MEMORY and SWAPDB commands. |
| Improvements | Active memory defragmentation, lazy freeing for deletions, cache eviction policies (allkeys-lfu, volatile-lfu), Lua sandboxing. |
| Cluster & Sentinel | Replicas can accept reads, Sentinel supports multiple monitoring per instance, improved hash slots migration. |
| Deprecated | The slave terminology in info and config output is deprecated in favor of replica. |
How does the new Modules system change Redis?
The module system is the biggest addition, allowing you to extend Redis with custom data types and commands at native speed. You write C code that hooks into the core, which means you can build features tailored to your data model without forking the server.
In practice, this led to the creation of modules for search (RediSearch), JSON (ReJSON), and graphs (RedisGraph). It turns Redis from a data structure server into a platform for building specialized databases.
What's better about replication with PSYNC2?
PSYNC2 enables partial resynchronization after a failover or network partition, even when the promoted replica has a different replication history. The old protocol could fail in these cases, forcing a full sync.
This matters because a full sync is expensive--it blocks the master, consumes network bandwidth, and increases failover time. PSYNC2 makes replication more resilient during cluster reorganizations.
Are there new ways to manage memory?
Yes, several. The MEMORY command gives you deep visibility into how memory is used per-key. Active defragmentation can reclaim memory fragmented by updates/deletions without a restart.
Lazy Freeing
You can now delete large keys (like big lists or hashes) in a non-blocking way using UNLINK or the LAZYFREE option. The server reclaims memory in a background thread, preventing latency spikes.
New Eviction Policies
The LFU (Least Frequently Used) policy is added for both allkeys and volatile eviction. This is often better than LRU for caching use cases where access patterns change over time.
What changes help with persistence and backups?
The new RDB-AOF hybrid persistence format is a big deal. When enabled, Redis appends AOF diffs to an RDB preamble. This gives you the fast restart of RDB with the durability of AOF.
For operations, the SWAPDB command lets you instantly swap two databases within the same Redis instance. This is useful for testing or quickly rolling back data without restarting.
How is Cluster and Sentinel improved?
Cluster replicas can now serve read-only traffic with the READONLY command, helping to scale out read operations. Hash slot migrations are also more reliable.
Sentinel can monitor multiple master names for the same Redis instance, simplifying setup when a single node hosts multiple logical databases. It also has better handling for certain network split scenarios.
FAQ
Should I upgrade to Redis 4.0 for the modules alone?
If you need a custom data type or command that Redis doesn't provide, absolutely. The module API is stable and powerful. For most users, the other features like PSYNC2 and memory improvements are also compelling reasons.
Does PSYNC2 work with my existing Redis 3.x replicas?
No, PSYNC2 requires both the master and replica to be running Redis 4.0 or later. You'll need to upgrade all nodes in a replication chain to benefit from the new protocol.
When should I use the new LFU eviction policy over LRU?
LFU is generally better for caching scenarios where you have popular items that are accessed repeatedly over time. LRU might be simpler if you just care about the most recently accessed items. You can test both with your workload.
Is the mixed RDB+AOF format the new default for persistence?
No, the default remains RDB-only. You need to explicitly enable it by setting aof-use-rdb-preamble yes in your configuration. It's a great middle-ground option if you're unsure.
What's the real benefit of the UNLINK command versus DEL?UNLINK is non-blocking. If you delete a 1GB hash with DEL, the server will freeze while it reclaims that memory. UNLINK just unlinks the key and lets a background thread do the heavy work, keeping your latency low.