Last checked and updated on 13 Jun 2026
What Is New in Redis 2.3
Redis 2.3 focuses on expanding data structure operations and enhancing replication stability. This release introduces new bitwise commands, improves master-slave sync reliability, and lays groundwork for future persistence changes.
| Category | Key Changes |
|---|---|
| New Commands | BITOP, BITCOUNT |
| Replication Improvements | More robust partial resynchronization, better handling of timeouts |
| Internal Changes | New hash table implementation, preparation for new save format |
| Bug Fixes | Fixes for issues in EXPIRE, MONITOR, and list commands |
What new bit operations does Redis 2.3 add?
Redis 2.3 adds the BITOP and BITCOUNT commands. This lets you perform bitwise operations (AND, OR, XOR, NOT) across multiple string keys and count set bits directly on stored values.
In practice, this turns Redis into a powerful tool for real-time analytics and feature flags. You can model daily active users or boolean arrays efficiently without client-side processing. The operations are atomic and fast.
Example Usage
SET key1 "a" # 'a' is 01100001 in binary
SET key2 "b" # 'b' is 01100010 in binary
BITOP AND result key1 key2
GET result # Returns "`" (01100000)
BITCOUNT key1 # Returns 3How is replication more reliable in this version?
The replication engine got tweaks to make partial resyncs more robust, especially after network hiccups. It better handles edge cases where a slave disconnects and reconnects quickly.
This matters because a flaky network won't force a full SYNC as often, saving bandwidth and time. The master-slave link stays usable under intermittent connectivity, which is common in cross-datacenter setups.
Are there under-the-hood changes affecting performance?
Yes, the internal hash table implementation was rewritten. It's more memory efficient and maintains the same O(1) performance for lookups. This change is transparent to users but improves baseline resource use.
They also started preparing for a new disk save format. While the old RDB format is still used, this groundwork allows for a future switch with less disruptive upgrades. You won't see a difference now, but it makes the next step easier.
What bugs were squashed in Redis 2.3?
Several edge-case bugs were fixed. Key ones involved the EXPIRE command with sub-millisecond keys, the MONITOR output formatting, and blocking operations on lists like BLPOP.
For example, a race condition in EXPIRE could sometimes cause a key to live slightly longer than intended. These fixes make behavior more predictable, which is critical for using Redis as a primary datastore.
FAQ
Should I upgrade to Redis 2.3 for the BITOP commands?
If you need bitwise analytics on large datasets stored in Redis, yes. The performance gain over doing it in your application is significant. If you don't use bit patterns, the replication fixes alone are a good reason.
Does the new hash table change how I write data?
No, it's completely internal. Your commands and data models remain the same. You might just see slightly lower memory usage for hash-valued keys.
Will upgrading break my existing replication setup?
It shouldn't. The replication protocol is backward compatible. Slaves running 2.2 can still sync with a 2.3 master. However, to get the new partial resync improvements, both sides should be on 2.3.
Is the RDB file format different now?
Not in this release. The changes are preparatory code refactoring. The actual on-disk format remains the same, so your current backups and persistence mechanisms work unchanged.
Were any commands deprecated in Redis 2.3?
No commands were deprecated in this release. It's an additive and stabilizing update. You can upgrade without changing your application code.