Redis Array Data Type Explained: 18 New Commands and Browser Playground Experience

Redis Welcomes a Brand New Array Data Type

Redis creator Salvatore Sanfilippo (antirez) recently submitted a major PR to Redis, introducing a completely new data type—Array. This is not only a significant expansion of Redis's data model, but what makes it even more noteworthy is that the development process heavily leveraged AI-assisted programming. Meanwhile, Simon Willison used Claude Code to build a WebAssembly-based browser interactive playground, allowing developers to experiment with these new commands without installing anything.

Since its birth in 2009, Redis has gradually built a rich system of data types. From the original String, List, Set, Sorted Set, and Hash, to later additions like HyperLogLog, Stream, Bitmap, and others—each data type is highly optimized for specific use cases. Redis's design philosophy has always revolved around its single-threaded event-driven architecture—all commands execute serially in one main thread, meaning every data structure operation must be fast enough, or it will block all subsequent requests. For this reason, Redis is extremely deliberate in its choice of data types: each type is carefully designed to find the optimal balance between memory efficiency and operational performance. For example, when the number of elements is small, Redis uses compact memory encoding formats (the earlier ziplist, unified as listpack after Redis 7.0) to reduce memory fragmentation and pointer overhead; when elements grow beyond a certain threshold, it automatically converts to underlying structures better suited for large-scale data. This "compact encoding for small data, specialized structures for large data" dual-layer design runs through virtually all Redis data types.

However, Redis has always lacked a true "array" structure—one that supports efficient random access, fixed-position indexing, and rich query capabilities in an ordered collection. The existing List type supports ordered storage, but its underlying implementation is based on quicklist (a hybrid of compressed lists and doubly linked lists), which has limitations in random access performance and feature richness. The introduction of the Array type is precisely meant to fill this gap.

Overview of Redis Array's 18 New Commands

This PR introduces 18 new commands at once, covering all aspects of array operations:

Basic Read/Write: ARSET, ARGET, ARMSET, ARMGET for single or batch element setting and retrieval
Range Operations: ARGETRANGE, ARDELRANGE support interval reading and deletion on arrays
Query and Traversal: ARSCAN, ARSEEK, ARNEXT provide cursor-based traversal capabilities
Information and Statistics: ARLEN, ARINFO, ARCOUNT retrieve array length, metadata, and counts
Insert and Delete: ARINSERT, ARDEL enable flexible element addition and removal
Advanced Features: AROP (arithmetic operations), ARRING (ring buffer), ARLASTITEMS (retrieve tail elements)

Among these, the cursor-based traversal (ARSCAN, ARSEEK, ARNEXT) design continues Redis's longstanding traversal philosophy. Developers familiar with Redis will recognize the SCAN, HSCAN, SSCAN, ZSCAN command family—they implement incremental traversal by returning cursors, avoiding the blocking issues that could occur when commands like KEYS or SMEMBERS return all data at once.

Behind this design lies deep engineering consideration. Redis's SCAN command uses an algorithm called reverse binary iteration for cursor advancement: the cursor value is not a simple incrementing sequence number, but generates the next cursor through high-bit incrementing of hash table slots. This seemingly counterintuitive design solves a tricky problem—during traversal, if the hash table undergoes rehash (expansion or contraction), traditional sequential traversal might miss elements or return duplicates, while the reverse binary iteration algorithm guarantees that even if the underlying data structure changes during traversal, all elements will eventually be visited (with possible minor duplicates, but no omissions). This guarantee is achieved without using any locks, perfectly aligning with Redis's single-threaded lock-free architecture.

Array's traversal commands adopt the same pattern: ARSCAN initiates traversal and returns a cursor, ARSEEK positions the cursor to a specified location, and ARNEXT advances step by step based on the cursor. This design is particularly important when handling large-scale arrays, ensuring that even if an array contains millions of elements, traversal operations won't block Redis's single-threaded event loop.

The ARRING (ring buffer) command is backed by a classic data structure concept—the ring buffer (also called circular buffer). A ring buffer uses fixed-size memory space, and when the write pointer reaches the end, it automatically wraps around to the beginning, overwriting the oldest data. This structure is extremely widespread in systems programming: OS kernel log buffers (like Linux's dmesg), network packet send/receive queues, and audio/video stream frame buffers all rely on ring buffers.

The reason ring buffers are so popular in high-performance systems comes down to two properties: fixed memory footprint and no data movement needed. Traditional arrays require shifting all subsequent elements forward when deleting from the head, with O(N) time complexity; a ring buffer only needs to move the read pointer, always O(1). In the lock-free programming domain, a single-producer-single-consumer (SPSC) ring buffer can even achieve thread-safe data transfer without any mutex locks or atomic operations, making it the preferred data structure in scenarios extremely sensitive to latency, such as high-frequency trading systems and real-time audio processing. It's worth noting that Redis's existing Stream type also provides similar capacity-limiting functionality—the MAXLEN parameter of the XADD command can limit the maximum length of a message stream, automatically trimming old messages. But ARRING is more semantically direct: it exposes the ring buffer as a first-class citizen to users, with lighter-weight operations, suitable for simple scenarios that don't need Stream's complex consumer group mechanisms.

In Redis application scenarios, ARRING is ideal for implementing fixed-capacity recent event logs, sliding window statistics, the latest N records of real-time monitoring data, and similar features, without developers having to manually maintain array sizes and element eviction logic.

This command set is thoughtfully designed, maintaining Redis's characteristic command-style simplicity while providing sufficiently rich operational semantics.

The ARGREP Command: Server-Side Regex Search in Redis

Among all the new commands, ARGREP is undoubtedly the most eye-catching. It allows executing grep-style regex matching searches directly on array values on the server side, with the TRE regular expression library integrated underneath.

TRE is a lightweight POSIX-compatible regular expression library written by Finnish developer Ville Laurikari. Its most distinctive feature is support for approximate matching—allowing a certain degree of edit distance tolerance (insertions, deletions, character substitutions) during matching, which is extremely valuable in fuzzy search scenarios.

To understand the significance of TRE as a technical choice, one needs to understand the two major schools of regex engines. Mainstream regex engines are divided into NFA (Nondeterministic Finite Automaton) and DFA (Deterministic Finite Automaton) implementations. Most programming languages (Python, Java, JavaScript) use NFA-based built-in regex engines, which try all possible matching paths through backtracking. They're powerful but have a fatal flaw: when regular expressions contain nested quantifiers (like (a+)+b) or complex alternation patterns, backtracking paths can grow exponentially, leading to so-called catastrophic backtracking—a carefully crafted input string can cause matching time to explode from milliseconds to hours or more, which is also the fundamental principle behind ReDoS (Regular Expression Denial of Service) attacks. DFA engines (like Google's RE2) guarantee linear time complexity but don't support advanced features like backreferences. TRE employs an innovative algorithm based on Tagged NFA (TNFA), which avoids backtracking issues through determinization while maintaining POSIX semantic compatibility, achieving O(N×M) time complexity (N being input length, M being regex length). For a latency-sensitive in-memory database like Redis, choosing TRE over PCRE (Perl Compatible Regular Expressions) is a deliberate engineering decision—a maliciously crafted regex that triggers catastrophic backtracking could block the Redis main thread for seconds or longer, causing all client requests to timeout. TRE fundamentally eliminates this risk.

ARGREP supports a rich combination of options:

MATCH: Specify the matching pattern
AND / OR: Logical combination of multiple conditions
LIMIT: Limit the number of returned results
WITHVALUES: Include matched values in results
NOCASE: Case-insensitive matching

For example, the command ARGREP myarr MATCH CHERRY AND LIMIT 10 WITHVALUES NOCASE searches array myarr for elements containing "CHERRY", ignoring case, returning at most 10 results with their values.

This means Redis is no longer just a simple key-value store—it now has rudimentary search capabilities at the data structure level. For scenarios requiring fast in-memory text data retrieval, this is an extremely valuable feature. It's worth noting that Redis previously offered full-text search capabilities through the RediSearch module, but that's a separate modular extension requiring independent installation and configuration, introducing inverted indexes and additional data structures with memory overhead. ARGREP, on the other hand, is search functionality built directly into the core data type, with a lower barrier to use and simpler deployment—it doesn't require pre-building indexes but instead scans array contents in real-time at query time, a design that's very practical for moderate data volumes (thousands to tens of thousands of records).

Browser-Side WebAssembly Playground Usage Guide

Simon Willison's Redis Array Playground is an elegant engineering achievement. It compiles a subset of Redis to WebAssembly, running directly in the browser, combined with a visual command builder UI that allows developers to:

Select commands to try from the left sidebar
Build command parameters through dropdown menus and input fields
View the generated complete command text in real-time
Click the run button to instantly get execution results

WebAssembly (Wasm for short) is a binary instruction format, originally standardized by the W3C, designed to provide near-native code execution performance for the web platform. Its core value is that programs written in system-level languages like C, C++, and Rust can be compiled into .wasm modules through toolchains like Emscripten, then run safely in the browser's sandbox environment.

Emscripten is the most critical toolchain in this ecosystem. It's essentially an LLVM-based compiler backend that compiles C/C++ code to WebAssembly bytecode, while providing a simulation layer for POSIX APIs—including a JavaScript-based virtual file system (MEMFS/IDBFS), network simulation based on Web APIs, and limited support for pthreads multithreading (implemented through Web Workers and SharedArrayBuffer). However, this simulation isn't perfect: Redis's deeply relied-upon epoll/kqueue I/O multiplexing mechanisms, the fork() system call (used for copy-on-write during RDB persistence), and TCP socket listening are either impossible to implement or require major modifications in the browser sandbox. Therefore, the Playground runs a functional subset of Redis, focusing on the core logic of data structure operations, stripping away networking, persistence, and clustering parts that are tightly coupled to the operating system.

This approach of "bringing server-side software to the browser" has become increasingly popular in recent years, with SQLite's Wasm version (sql.js) and PostgreSQL's PGlite being similar success stories. Another noteworthy development direction is the WASI (WebAssembly System Interface) standard—it attempts to define a standardized system interface for WebAssembly, enabling Wasm modules to run not only in browsers but also on servers, edge computing nodes, and any other environment in a unified manner. Docker co-founder Solomon Hykes famously said, "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker."

This playground itself is also a product of AI-assisted development—Simon used Claude Code for Web to build it, with the entire process documented in GitHub PR #277.

Dual Validation of AI-Assisted Development

This project presents an interesting phenomenon: the Redis Array type itself is a product of AI-assisted development, and the Playground tool for experiencing it was also built with AI assistance.

Salvatore detailed the AI-assisted development process for the Array type in his blog post Redis array type: short story of a long development. As Redis's creator, he provides firsthand experience on the practical application of AI in system-level C language development.

These two cases together illustrate a trend: AI-assisted programming is evolving from simple code completion to being capable of participating in complex system design and full-stack tool development. Whether it's low-level C data structure implementation or frontend WebAssembly interactive applications, AI has demonstrated substantive productivity contributions. This trend aligns with broader industry observations—GitHub Copilot's 2024 data shows that developers accept over 30% of AI-suggested code, with even higher ratios in certain languages (like Python and JavaScript). But Salvatore's case is more convincing because system-level C development is generally considered one of the areas where AI-assisted programming is hardest to apply effectively: it demands precise control over low-level details like memory management, pointer operations, and concurrency safety, with extremely small margins for error. A single buffer overflow or use-after-free error could lead to security vulnerabilities or data corruption, and such errors are often difficult to detect through code review and routine testing, requiring specialized tools like Valgrind and AddressSanitizer. AI's ability to provide effective assistance in this domain marks a new level in its code understanding and generation capabilities.

Redis Array vs. Existing Data Structures

Currently, the Array type implementation is still in a branch stage, not yet merged into the main line. But if ultimately adopted, it will fill Redis's gap in ordered, indexable, server-side searchable array structures:

Compared to List type: Array provides richer random access and regex search capabilities. Redis's List uses quicklist (after Redis 3.2), which is essentially a doubly linked list composed of multiple ziplist nodes (changed to listpack after Redis 7.0). This structure is very efficient for head/tail operations (LPUSH/RPUSH/LPOP/RPOP) with O(1) time complexity, but random access by index (LINDEX) has O(N) time complexity, requiring traversal from the head or tail of the linked list. More specifically, each quicklist node is a listpack (contiguous memory block), with nodes connected through bidirectional pointers. To access the Kth element, Redis needs to first determine which listpack node it's in (traversing the node list), then perform a linear scan within that node. Although Redis records the number of elements in each node to speed up positioning, it still needs to traverse multiple nodes in the worst case. The Array type is expected to significantly improve random access performance, likely using contiguous memory layout or tree-indexed structures to achieve O(1) or O(log N) index access.
Compared to Sorted Set: Array is better suited for scenarios requiring preserved insertion order and positional indexing. Sorted Set maintains ordering through scores, using a combination of skip lists and hash tables, excelling at range queries and ranking operations, but doesn't support index access by insertion position. Skip lists are probabilistic data structures that achieve O(log N) lookup, insertion, and deletion through multi-level indexing. Redis chose skip lists over balanced binary trees (like red-black trees) because skip lists are simpler to implement, more natural for range queries (just traverse sequentially on the bottom-level list), and more concurrency-friendly. But Sorted Set's ordering is based on score values rather than insertion position—if you need semantics like "the 100th element inserted," Sorted Set cannot directly satisfy this.
Unique Advantage: Server-side regex search through ARGREP is something no other data type offers

It's worth mentioning that in March 2024, Redis changed its license from the BSD 3-Clause License to a dual-license model of SSPLv1 (Server Side Public License) and RSALv2 (Redis Source Available License v2). The deep background of this change lies in a core conflict in open-source commercialization in recent years: cloud providers like AWS, Google Cloud, and Azure can directly offer open-source software as managed services to users, generating enormous revenue without contributing any code or revenue back to original developers. MongoDB pioneered the adoption of SSPL in 2018 to address this issue, followed by Elastic, HashiCorp, and others. SSPL's core clause requires: if you provide SSPL-licensed software as a service to third parties, you must open-source the entire service stack (including all related software for management, monitoring, deployment, etc.) under SSPL. This clause effectively makes it nearly impossible for cloud vendors to offer managed services without open-sourcing their entire cloud platform, which is why the OSI (Open Source Initiative) has explicitly stated that SSPL does not meet the open-source definition.

This change sparked widespread discussion in the open-source community and spawned alternative projects like Valkey (a Redis fork hosted by the Linux Foundation). Valkey forked from Redis 7.2.4 (the last BSD-licensed version), jointly supported by AWS, Google, Oracle, Ericsson, and others, committed to maintaining a truly open-source license (BSD). Valkey has already released multiple independent versions and begun introducing its own feature branches. Whether the Array type, as a significant new feature after the license change, will be adopted by fork projects like Valkey is a noteworthy development to follow—since the Array type code will be released under SSPL/RSALv2, Valkey cannot directly merge this code and would need to independently implement similar functionality, potentially leading to divergence between the two projects at the data type level.

For developers following Redis's evolution, you can already get a head start on understanding these new commands through the browser-based Playground, preparing for future technology decisions.

Key Takeaways

Redis creator Salvatore Sanfilippo submitted a PR adding the Array data type to Redis, including 18 new commands
The ARGREP command supports server-side regex search, integrating the TRE regex library, enabling case-insensitive, multi-condition combined searches of array contents
Simon Willison used Claude Code to build a WebAssembly-based browser interactive playground, allowing hands-on experience with new commands without installation
Both the Redis Array type and the Playground tool are products of AI-assisted development, demonstrating AI's practical application in system-level and full-stack development
The Array type is currently in a branch stage; if merged into mainline, it will fill Redis's gap in indexable, searchable array structures