Redis: From a Sicilian Startup to a License War

The Problem That Started It

In 2009, Salvatore Sanfilippo — known online as antirez — was running a startup called Merzia out of Sicily. The product was LLOOGG, a real-time web analytics tool. Users could embed a snippet on their site and watch page views appear in a live feed. Simple concept, but it had a scaling problem that turned out to matter more than the product itself.

LLOOGG tracked the last N pageviews for each site it monitored. Every time a new pageview came in, the system needed to add it to the list and drop the oldest entry if the list exceeded the configured limit. Antirez was using MySQL. The operation was: fetch the current list, deserialize it, append the new entry, truncate if necessary, serialize, write back. For one site this was fine. For many sites with frequent updates, it was a bottleneck that couldn't be fixed by adding more MySQL.

The insight was not "we need a faster database." The insight was more specific than that: he needed a data structure server, not a key-value store. He needed something that understood what a list was and could push and pop from it atomically, without the application having to round-trip the full serialized value on every write.

He built a prototype in Tcl. Roughly 300 lines. The prototype implemented in-memory key-value storage with list support, and used fork-based persistence — the process would fork itself and the child would write the memory contents to disk while the parent continued serving requests. Fork-based persistence is the approach Redis still uses for RDB snapshots today, sixteen years later.

Port 6379 was not chosen arbitrarily. On old phone keypads, 6379 spells "MERZ" — the first four letters of Merzia. It's a small detail, but it's the kind of thing you notice when you read about Redis's history: antirez built it as a craftsman builds things, with deliberate choices and personal touches embedded in the infrastructure.

The C Rewrite and Open Source Release

The Tcl prototype worked well enough to solve the LLOOGG problem. But Tcl had limits. Performance was one; portability was another. Antirez rewrote Redis in C and released it publicly in 2009.

The timing was good. Memcached was the dominant in-memory caching solution at the time, and it was excellent at what it did — but what it did was store and retrieve byte strings. If you needed a counter, you had to fetch the value, increment it in application code, and write it back, accepting that another process might have done the same thing between your read and your write. If you needed a list, you serialized it, stored the blob, fetched it, deserialized it, appended, serialized again, wrote it back. The application owned the data structure logic; the cache was a dumb store.

Redis offered something different. LPUSH appended to a list. LRANGE retrieved a slice without loading the whole structure. INCR atomically incremented a counter. ZADD added a scored element to a sorted set. HSET set a field in a hash. These were not novelties — you could implement all of them in application code against Memcached or any other key-value store. What Redis offered was correctness without the boilerplate. You got atomic operations, no serialization round-trips, and behavior that was defined at the protocol level rather than reconstructed in every application that touched the data.

The C codebase reflected antirez's priorities. He was deliberate about code readability. The source files are short by systems software standards, the variable names are descriptive, and the abstractions are shallow enough that you can trace execution from a client command to the point where bits hit the network buffer without losing the thread. This wasn't accidental — antirez wrote publicly about software aesthetics, and the Redis codebase was something he cared about as a piece of writing, not just a piece of machinery.

The Adoption Wave

Redis got no marketing budget in its early years because there was no company behind it yet. The adoption was entirely organic, and it came fast.

GitHub's Resque was one of the earliest high-profile uses. Resque was a Ruby background job system — jobs were represented as JSON objects pushed onto Redis lists, workers popped from those lists and executed the jobs. The simplicity of the model matched the simplicity of the Redis data structure: a list you push onto and pop from, nothing more.

Instagram used Redis extensively in its early data layer. Twitter used it for fanout in its timeline system — when a user with millions of followers posts a tweet, the system needs to push that tweet ID into potentially millions of lists, fast. Redis lists, operated from multiple workers, made this tractable.

The pattern across all these early adopters was the same: not "use Redis as a cache," but "use Redis as the authoritative store for a specific, high-volume data structure." Sorted sets for leaderboards. Lists for queues and timelines. Sets for unique visitor counting. Hashes for user session objects. Each use case replaced a pattern that had previously required either a relational database query with joins and transactions, or a Memcached round-trip with application-level data structure management.

Redis Labs and the BDFL Years

Redis Labs was founded in 2011 to commercialize Redis. The company hired antirez, and he remained Redis's BDFL — Benevolent Dictator for Life — while the company built hosted Redis services and enterprise add-ons.

The relationship between antirez and Redis Labs was productive but had inherent tension. Antirez was a programmer who wanted to write code. Redis Labs was a company that needed a community, roadmap, marketing, and enterprise features. He describes the community management dimension of open source — the GitHub issues, the community expectations, the political navigation — as genuinely draining in a way that writing code was not.

For most of the 2010s, this tension stayed manageable. Redis gained features: persistence improvements, cluster mode, Lua scripting, modules (which let external code extend Redis with new data types and commands), streams (a log-structured data type added in 4.0). The project remained licensed under BSD — simple, permissive, compatible with essentially everything.

"The End of the Redis Adventure"

In June 2020, antirez published a blog post titled "The end of the Redis adventure." It is one of the more honest things a prominent open source developer has written about why they stepped back from a major project.

His explanation was not burnout in the usual sense. He was not exhausted from too much work. He was specific: "I write code to express myself, and I naturally became less interested in doing that in the Redis context as the community became something I had to manage rather than something I was part of." He described a growing gap between what he found interesting — clean abstractions, elegant code, novel data structure problems — and what the job actually required, which included issue triage, roadmap negotiation, and community diplomacy.

He handed technical leadership to Yossi Gottlieb and Oran Agra, two Redis Inc. engineers who had been working on the project for years and who were better suited to that dimension of the work. He remained available as an advisor. The transition was orderly. Redis continued.

The License Earthquake

In March 2024, Redis Inc. announced that Redis 7.4 would no longer be released under the BSD 3-Clause license. The new license was dual: RSALv2 (Redis Source Available License version 2) and SSPLv1 (Server Side Public License version 1). The stated reason was straightforward — major cloud providers, specifically AWS with its ElastiCache managed Redis service, were generating substantial revenue from Redis without contributing meaningfully to its development. The RSALv2/SSPL combination was designed to close that gap: you could use Redis freely, but if you offered it as a managed cloud service, you were obligated to either open-source your entire service stack (SSPL) or obtain a commercial license from Redis Inc.

The community response was immediate and angry. The core objection was definitional: neither RSALv2 nor SSPL meet the Open Source Initiative's definition of open source. This is not a technicality. The OSI definition is the agreed-upon reference point for what "open source" means in enterprise procurement, legal reviews, and license compatibility. By that definition, Redis was no longer open source.

The Linux Foundation's response came within days. They announced Valkey, a fork of Redis 7.2 (the last BSD-licensed version), to be developed under the Linux Foundation umbrella. The initial backing was substantial: AWS, Google Cloud, Oracle, Ericsson, and Snap all announced support. Valkey promised binary and protocol compatibility with Redis — the same wire protocol, the same data model, the same configuration format.

A Percona survey conducted later in 2024 found that 83% of large enterprises were evaluating Valkey as a Redis replacement. That number represents adoption intent more than actual migration, but it indicates the scale of the credibility damage to Redis Inc.'s commercial story.

antirez Returns

In November 2024, antirez announced he was rejoining Redis Inc. He did not publish an extended explanation. The announcement was brief: he was back, he was interested in working on Redis again, that was that.

In May 2025, Redis Inc. added AGPLv3 as a third license option alongside RSALv2 and SSPL. AGPLv3 is a genuine OSI-approved open source license — it requires that modifications be released if you operate modified software as a network service, but it is open source in the technical sense. This was a partial concession to the community criticism.

Redis 8.0 and the Product Pivot

Redis 8.0, released in 2024, merged several capabilities that had previously been separate commercial modules into the open-source core: RediSearch (full-text search), RedisJSON (native JSON storage and querying), RedisTimeSeries, and RedisBloom (probabilistic data structures including Bloom filters and HyperLogLog extensions).

This was a significant product strategy shift. By merging them into the core, Redis Inc. changed the competitive calculus against Valkey: core Redis became feature-richer, but also more tightly coupled to Redis Inc.'s commercial interests since the merged-in modules remained under the tri-license rather than reverting to BSD.

Where Things Stand

As of 2026, the Redis ecosystem is divided in a way that was not true before March 2024.

Redis Inc. controls the Redis trademark and the primary codebase. Redis 8.x is feature-complete and actively developed, with a growing surface area from the merged modules. Valkey is the Linux Foundation-backed fork, now at version 8.x on its own release track, BSD-licensed with broad cloud provider backing.

What is not in question is the technical contribution. The event loop, the incremental rehashing, the sorted set with dual skip list and dict indexing, the fork-based persistence — these are genuinely well-designed systems that have held up under a decade and a half of production load at internet scale. Whatever the licensing history, the source code is worth reading.