Redis Array Data Type Explained: 18 New Commands and a WASM Online Playground

Overview

Redis creator Salvatore Sanfilippo (antirez) recently submitted a major PR to Redis, introducing a brand-new data type — Array — along with 18 entirely new commands in one go. Meanwhile, Simon Willison used Claude Code to build a WebAssembly-based interactive playground that runs in the browser, allowing developers to experiment with these new commands online without installing anything.

Background: The Evolution of Redis Data Types

Since its release in 2009, Redis's core data types have undergone multiple expansions. Initially supporting only five basic types — String, List, Set, Sorted Set, and Hash — Redis later added HyperLogLog (2014, for cardinality estimation), Bitmap and Bitfield (technically bit-operation extensions of the String type), Geo (2015, a geospatial index built on Sorted Sets), Stream (2018, for message queues and event sourcing), and more.

Redis's data model design follows a core philosophy: every data type must provide clear time complexity guarantees and be optimized for specific access patterns in terms of memory efficiency. For example, when a Hash contains a small number of fields, Redis automatically uses listpack (formerly ziplist) — a compact encoding that saves memory — and only switches to a real hash table when the element count exceeds a threshold. This dual-layer design of "compact encoding for small data, efficient structures for large data" runs through all Redis data types.

Notably, Redis introduced the Modules API in version 4.0 (2017), allowing third parties to extend custom data types via dynamic loading, such as RedisJSON, RedisGraph, and RedisTimeSeries. However, the Array type is being added directly to the Redis core codebase as a native type, meaning it will receive the same level of optimization and maintenance as String, List, and others, without depending on additional module loading. This marks the first time in years that Redis has introduced a completely new fundamental data structure at the core level, signaling another important evolution in Redis's data model richness.

Redis Array Data Type: A Complete Breakdown of 18 New Commands

This PR introduces a complete set of operations for the Array type, totaling 18 commands. Categorized by function:

• Basic operations: ARSET, ARGET, ARLEN, ARINFO
• Bulk operations: ARMGET, ARMSET
• Range operations: ARGETRANGE, ARDELRANGE
• Insert and delete: ARINSERT, ARDEL
• Traversal and search: ARSCAN, ARSEEK, ARNEXT, ARGREP
• Others: ARCOUNT, AROP, ARRING, ARLASTITEMS

This command set covers core scenarios for array data structures including CRUD, range operations, traversal, and pattern matching.

Underlying Structural Differences Between Array and List

Redis's existing List type uses a quicklist implementation under the hood (earlier versions used a hybrid ziplist + linkedlist structure). A quicklist is essentially a doubly-linked list composed of multiple listpack nodes (ziplist before Redis 7.0). Each listpack node is a contiguous block of memory storing several elements internally; nodes are linked via pointers. Redis controls the maximum size of each node through the list-max-listpack-size configuration, and can apply LZF compression to middle nodes via list-compress-depth to save memory.

The core trade-off of this design: head/tail operations (LPUSH/RPUSH/LPOP/RPOP) are O(1), but accessing elements by index (LINDEX) has O(N) time complexity, requiring traversal from head or tail to the target position. While quicklist reduces traversal steps through chunking, it's still fundamentally a linear search.

The Array type is expected to use a contiguous memory layout, supporting O(1) random access. Contiguous memory layout also brings an important performance advantage: CPU cache friendliness. Modern CPUs load data into L1/L2/L3 caches in cache lines (typically 64 bytes). Contiguous memory layout means that when accessing one element, adjacent elements are likely already prefetched into the cache, making subsequent accesses nearly zero-latency. In contrast, linked list nodes are scattered throughout memory, and each pointer dereference may trigger a cache miss, resulting in performance differences of several times under large data volumes.

Time complexity comparison:

Operation	List (quicklist)	Array
Head/tail insert/delete	O(1)	O(N) (requires shifting elements)
Access by index	O(N)	O(1)
Insert by index	O(N)	O(N) (requires shifting elements)
Range query	O(S+N)	O(N) (contiguous memory copy)

This underlying difference fundamentally determines their different use cases: List is suited for queue/stack scenarios with head/tail operations, while Array is suited for scenarios requiring frequent positional reads and writes. Thus, Array provides more powerful random access and index-based operation capabilities, adding a more flexible sequential storage option to Redis's data model.

ARGREP: Server-Side Regex Search Command

Among the 18 new commands, ARGREP deserves the most attention. It allows users to perform grep operations directly on array values on the server side, supporting regular expression matching. It integrates the TRE regular expression library under the hood — a lightweight regex engine that supports approximate matching.

Technical Characteristics of the TRE Regex Library

TRE (Tre Regular Expressions) is a POSIX-compatible regular expression library developed by Ville Laurikari. Its standout feature is support for approximate matching — allowing fuzzy matches within a specified edit distance (number of insertions, deletions, and substitutions). This is fundamentally different from traditional regex engines that only support exact pattern matching. For example, the search pattern "redis" with an allowed edit distance of 1 can match "rediS", "redis1", and various spelling variants of "redis" — extremely valuable for fuzzy user input searches, approximate text matching in logs, and similar scenarios.

TRE uses a tagged NFA-based algorithm, guaranteeing linear time complexity O(M×N) matching performance (where M is the pattern length and N is the text length), avoiding the catastrophic backtracking problem found in some regex engines. Catastrophic backtracking occurs when regular expressions contain nested quantifiers (like (a+)+b), causing backtracking engines (such as PCRE, Java regex) to produce exponential time complexity on non-matching inputs — in extreme cases, a short regex can lock up a CPU for minutes. This problem has caused multiple production incidents, including Cloudflare's 2019 global outage.

In the spectrum of regex engine choices, common alternatives include: PCRE2 (most feature-rich, supporting backreferences and other advanced features, but with backtracking risk), Google RE2 (guarantees linear time but doesn't support approximate matching), and Intel Hyperscan (a SIMD-accelerated engine for high-throughput network scenarios). In Redis — a single-threaded system extremely sensitive to latency — choosing TRE over heavier regex libraries like PCRE reflects dual considerations of performance and safety: avoiding backtracking risk while gaining the unique capability of approximate matching.

ARGREP Supported Option Combinations

ARGREP supports multiple option combinations:

• MATCH: Specify the matching pattern
• AND / OR: Multi-condition logical combinations
• LIMIT: Limit the number of returned results
• WITHVALUES: Return the actual matched values
• NOCASE: Case-insensitive matching

Architectural Trade-offs: Server-Side vs. Client-Side Filtering

With ARGREP, developers can perform complex text searches directly at the Redis layer without pulling all the data to the client for filtering. This design reflects a classic architectural decision in distributed systems: where to place data filtering.

Client-side filtering means transferring the full dataset over the network to the application layer for screening. When data volumes are large, this causes severe bandwidth waste and increased latency. Suppose an array contains 100,000 elements but only 100 match the target pattern — client-side filtering requires transmitting all 100,000 elements, while server-side filtering only returns 100 results. In typical microservice architectures, the network round-trip time (RTT) between Redis and application servers is usually 0.1-1ms, but the serialization/deserialization overhead and bandwidth consumption of large data transfers are often bigger bottlenecks.

Server-side filtering pushes computation down to the data storage layer, returning only the qualifying result set and significantly reducing network I/O. This aligns with the "predicate pushdown" optimization philosophy in the database field. Similar designs are widespread in modern data systems: Apache Parquet's column pruning and row group filtering, ClickHouse's PREWHERE clause, Amazon S3 Select allowing SQL filtering at the object storage layer, and even Linux kernel's eBPF pushing packet filtering logic into kernel space to avoid user-space copying.

However, server-side filtering also has costs: complex regex matching consumes CPU time on Redis's main thread, potentially affecting response latency for other commands. Redis's single-threaded event loop model means any command that takes too long to execute blocks all subsequent commands — this is why Redis's official documentation has always warned about the danger of the KEYS * command in production environments. Therefore, the LIMIT parameter exists not only as a functional necessity but also as a performance protection mechanism, ensuring that even with many matching results, the command can return early after scanning a sufficient quantity. The design of ARSCAN and cursor mechanisms (ARSEEK/ARNEXT) follows the same philosophy — splitting large-range scans into multiple small-batch operations to avoid prolonged blocking.

In scenarios involving log storage, tag lists, and text records, judicious use of ARGREP can significantly reduce network transfer overhead and improve query efficiency.

Browser-Side WASM Playground: Zero-Install Redis Array Experience

Technical Implementation

Simon Willison used Claude Code for Web to build a complete Redis Array Playground. This tool compiles a subset of Redis to WebAssembly (WASM), running a real Redis instance directly in the browser. Open the page and start testing — no local environment setup or remote server connections needed.

WebAssembly in Developer Tools

WebAssembly is a low-level bytecode format originally designed to let programs written in C/C++/Rust run in browsers at near-native speed. WASM's development went through several key stages: Mozilla proposed asm.js in 2013 (a strict JavaScript subset that could be AOT-compiled for optimization); in 2015, Google, Mozilla, Microsoft, and Apple jointly launched the WebAssembly project; WASM 1.0 achieved support in all major browsers in 2017; subsequently, proposals for multi-threading (SharedArrayBuffer + Atomics), SIMD instructions, exception handling, GC (garbage collection), and more were added.

Compiling Redis to WASM requires solving several key technical challenges:

System call emulation: Redis's dependencies on network I/O, file systems, time functions, and other operations need to be bridged through an adaptation layer. There are currently two main paths: one uses the Emscripten toolchain, which provides a complete POSIX API emulation layer, mapping file operations to the browser's in-memory file system (MEMFS) and network operations to WebSocket; the other uses WASI (WebAssembly System Interface), a standardized system interface specification designed to let WASM programs access OS capabilities in a unified way, not limited to browser environments. For a Redis Playground scenario where no real network communication is needed (all operations are local), the main thing to emulate is the core path of memory allocation and command parsing/execution.

Memory management: WASM runs in a sandboxed environment with a linear memory space (configurable default starting size, maximum up to 4GB), where programs access memory via offsets. Redis's jemalloc or libc malloc needs to work on this linear memory, and memory growth requires explicit memory.grow instructions.

Similar technical approaches have been successfully validated by multiple projects: SQLite compiled to WASM (sql.js and the official sqlite3.wasm), Python running in browsers (the Pyodide project, based on Emscripten-compiled CPython interpreter), a browser version of PostgreSQL (PGlite), and even a complete Linux kernel (the v86 project). These cases prove the feasibility of bringing server-side software to the browser, and have catalyzed a new trend of "local-first" developer tools.

Interaction Design

This WASM playground provides an intuitive command builder interface:

• Left sidebar lists all available Array commands
• Main panel provides a visual parameter configuration interface with dropdowns, checkboxes, and other interactive elements
• Bottom area displays the complete constructed command string in real-time
• Click "Run command" to execute and view the returned result

This design lowers the barrier to learning new commands to a minimum — no need to memorize syntax or browse documentation. You can explore each command's parameter combinations and actual behavior through the interface. This interactive documentation philosophy aligns with tools like Jupyter Notebook, Observable, and Swagger UI: the best documentation isn't static text descriptions, but living documents you can run and experiment with directly.

Two Case Studies in AI-Assisted Development

antirez Using AI to Develop the Array Type

Salvatore documented the Array type's development process in detail in his blog post Redis array type: short story of a long development. As Redis's creator, he shared his experience of effectively leveraging AI tools in complex systems-level C programming — which aspects are suitable for delegating to AI and which still require human judgment.

In systems-level programming, AI assistance faces fundamentally different challenges compared to application-layer development: memory management requires precise control (an off-by-one error in Redis could cause data corruption), concurrency models require deep understanding of event loop semantics, and performance optimization requires intuitive understanding of CPU cache hierarchies and memory access patterns. antirez's experience shows that AI is highly efficient at generating boilerplate code, implementing algorithms with clear specifications, and writing test cases, but architectural decisions, edge case handling, and optimization of performance-critical paths still require senior engineers' judgment.

Simon Willison Using Claude Code to Build the WASM Tool

Simon Willison demonstrated another direction of AI-assisted development: using Claude Code to rapidly build developer tools. Claude Code is Anthropic's command-line AI coding agent tool, which is fundamentally different from traditional code completion assistants (like GitHub Copilot's inline suggestion mode): rather than providing next-line code suggestions at the cursor position, it can autonomously plan tasks, read and write files, execute shell commands, observe output results, and iteratively fix errors, forming a complete "perceive-plan-act-feedback" loop.

Agentic Engineering is currently the most cutting-edge paradigm in AI-assisted programming, referring to using such AI agents to complete end-to-end software engineering tasks rather than just providing suggestions at the individual code snippet level. The related tool ecosystem is rapidly evolving: besides Claude Code, there's Cursor's Agent mode, Devin (Cognition Labs), OpenAI's Codex CLI, Aider, and more. These tools share common characteristics: multi-step reasoning capability, tool-calling capability (reading/writing files, executing commands, browsing the web), and self-correction capability.

In this case, Claude Code needed to understand Redis source code structure, configure the Emscripten/WASI compilation toolchain, generate an interactive frontend interface, and ensure all components connected correctly — this kind of coordination across multiple technology stacks (C systems programming → WASM compilation toolchain → JavaScript/HTML frontend) is precisely where Agentic Engineering delivers core value. In traditional development, such cross-stack tasks often require developers to switch back and forth between multiple documentation sources and repeatedly debug compilation configurations, while AI agents can integrate these fragmented pieces of knowledge into a coherent execution flow. Based on the PR records, the entire WASM compilation configuration and interactive UI scaffolding process was highly automated, demonstrating the practical efficiency of AI agents in toolchain development.

Comparing Two AI-Assisted Modes

These two cases represent two typical modes of AI-assisted development:

Dimension	antirez Mode (AI as Assistant)	Simon Mode (AI as Agent)
Human role	Architect + Decision maker	Requirements definer + Acceptor
AI autonomy	Low (step-by-step guidance)	High (end-to-end execution)
Suitable scenarios	Core system code, performance-critical paths	Tools/prototypes/one-off scripts
Error tolerance	Very low (bugs affect all users)	Higher (can quickly iterate and fix)
Code review needs	Line-by-line review	Primarily functional acceptance

The choice between these two modes depends on the code's criticality and error tolerance. For Redis core data structures that will be relied upon by millions of production systems, every line needs rigorous review; for a demonstration Playground tool, rapid delivery and usability matter more than code perfection. Understanding this distinction is key to effectively leveraging AI programming tools in practice.

Redis Array's Positioning and Future Outlook

The introduction of the Redis Array type fills a gap in Redis's ordered, indexable sequential data structures. Although Redis already has a List type, List is essentially a linked list structure with limited random access and range query performance. Array provides more efficient random access, range queries, and server-side regex search capabilities, making it better suited for scenarios requiring frequent index-based reads and writes.

From an application perspective, the Array type may deliver unique value in the following areas:

• Time-series sliding windows: Storing the most recent N data points, quickly accessing values at any time position via index, combined with ARRING (ring buffer semantics) to implement fixed-size rolling windows
• Leaderboard snapshots: Unlike Sorted Sets, Array can store a complete ranking snapshot at a point in time, supporting O(1) queries for "who is ranked Kth"
• Feature vector storage: In machine learning scenarios, storing user/item feature vectors as Arrays for fast dimension-wise access
• Paginated data caching: Pre-computed pagination results stored directly as Arrays, achieving O(1) pagination queries via ARGETRANGE
• Configuration sequences: Ordered lists of configuration items requiring precise positional reads and writes

It's worth considering the relationship between the Array type and Redis's module ecosystem. Previously, similar needs could be met through RedisJSON (storing JSON arrays with JSONPath query support) or custom modules. But native types have clear advantages: no extra module deployment needed, long-term maintenance and optimization from the Redis core team, seamless integration with RDB/AOF persistence and master-slave replication infrastructure, and automatic support from all Redis client libraries.

Currently, this implementation is still in a branch stage and hasn't been merged into the Redis mainline. However, given the PR's completeness (18 commands, comprehensive test cases) and supporting tools (WASM Playground), this feature is likely to be officially released in a future Redis version. It's worth noting that Redis changed its license from BSD to RSALv2 + SSPLv1 dual license in 2024, which spawned alternative projects like Valkey (a Redis fork led by the Linux Foundation). As a new feature after the license change, Array type's availability in forks like Valkey depends on each project's independent development decisions.

If your project needs to store and query structured sequential data in Redis, the Array type is worth keeping an eye on. We recommend first getting hands-on experience through the online Playground to familiarize yourself with these new commands' usage in advance.

Key Takeaways

• Redis creator Salvatore Sanfilippo submitted a PR adding a new Array data type to Redis, featuring 18 new commands
• The ARGREP command supports server-side regex search, integrating the TRE regex library for approximate matching
• Simon Willison used Claude Code to build a WASM-based browser interactive playground, enabling zero-install experimentation
• The project simultaneously demonstrates practical value in two directions: AI-assisted systems-level programming and rapid toolchain construction
• The Array type is still in a development branch, offering richer random access and range query capabilities than List