Redis Development Roadmap: Clarifications on RESP3, ACLs, Multithreading, Storage and Data Structures
In this article, Redis creator Antirez explains the rationale behind upcoming features such as RESP3, fine‑grained ACLs, multithreading approaches, storage improvements, and new data structures, while emphasizing the lack of a fixed roadmap and the community‑driven nature of Redis development.
Redis author Antirez uses this post to clarify the direction of several key features that have generated discussion among users, noting that Redis does not have a reliable long‑term roadmap and that development decisions evolve based on community feedback.
RESP3 – The goal of RESP3 is to simplify client implementations by providing richer response metadata, such as reply attributes, without requiring clients to know command semantics in advance. While client‑side caching will benefit from these attributes, Redis 6 will retain full backward compatibility with RESP2, and the attribute support will not be shipped in that release.
ACLs – After revisiting the ACL specification four years ago, Antirez decided to implement it to address operational needs rather than purely security concerns. ACLs enable administrators to prevent dangerous commands (e.g., FLUSHALL , KEYS ) from being executed by untrusted users or libraries, improving operational safety with minimal CPU overhead.
Multithreading – Two multithreading models are discussed: an I/O‑thread model that would parallelize request handling (similar to Memcached) and a slow‑command thread model that offloads long‑running commands. The I/O‑thread approach is deemed too complex for Redis, so the focus shifts to handling slow operations via module‑level key‑level locking and careful synchronization.
Better Storage – Recent work includes a pre‑amble for RDB data in AOF files and numerous replication improvements, representing a significant step forward in Redis’s persistence capabilities.
Data Structures – Since Redis 5, streams have been supported, and future releases (Redis 6/7) aim to optimize existing structures for memory efficiency. Adding new structures such as HyperLogLog extensions, advanced bit operations, and blocking sorted‑set commands is considered valuable, but each addition requires careful evaluation.
Conclusion – Antirez stresses the importance of transparent communication with the community, using blogs and Twitter to explain why certain features are prioritized or delayed. He acknowledges the small core team size, the iterative nature of the roadmap, and the freedom afforded by Redis Labs to pursue open‑source innovation.
High Availability Architecture
Official account for High Availability Architecture.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.