{"slug": "redis-and-the-cost-of-ambition", "title": "Redis and the Cost of Ambition", "summary": "Redis creator antirez submitted a pull request in 2026 adding a new array type to Redis, highlighting the project's ongoing identity crisis as it strays from its original purpose as a lightweight data structure server. Once a simple \"memcached but way better\" solution that dominated web stacks through tastefully limited data types like linked-lists and hash-tables, Redis has accumulated features such as ACLs, JSON, time-series, and sorted-sets in an attempt to become a full-fledged database. The project's ambition to serve every use case has diluted its core identity, leaving it struggling with enterprise DBaaS dynamics and second-system effects that threaten the simplicity that made it indispensable.", "body_md": "I recently skimmed antirez's patch for adding an [array type](https://github.com/redis/redis/pull/15162)\nto Redis. The patch itself is not particularly noteworthy except as an example\nof how AI-assisted tooling can augment the abilities of a talented and tasteful\nsystems engineer. What got me thinking was antirez' prose in the top of the\npull-request, explaining the rationale for an array type:\n\nHashes give you random lookups, but you have to store an index as a key, and have no range visibility. Lists give you appending and trimming, but what is in the middle remains hard to access. Streams give you append-only events, which is another (useful, indeed) beast.\n\nHe could have also mentioned Redis' other array-ish faculties like JSON which has arrays natively, time-series, and sorted-sets, which can be made to behave like an array in some situations. Here we are in 2026, Redis is in a bit of a crisis, and yet is sitting with a massive PR to add a new array type. What is going on?\n\nRedis has been through a lot over the last decade, driven partly by enterprise DBaaS dynamics, partly by second-system effects:\n\nWhat happened to dear old Redis, I wondered. And the more I thought about it, a satisfying explanation started to coalesce which explains all the above phenomena. To me, the picture that emerges is that of a solution that lost its identity through ambition.\n\nI would put it some time around 2011...that time of excitement when so many new\nideas were coming in vogue among web and web-adjacent developer circles. When\nNoSQL was blasting off into its hype cycle, *web scale* was not used ironically,\nand the [Bigtable](https://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf)\nand [Dynamo](https://www.amazon.science/publications/dynamo-amazons-highly-available-key-value-store)\npapers were still widely read and discussed. Alongside this were Ruby on Rails,\n*elegance* (a desirable property for CRUD apps), web 2.0, REST and JSON. [Redis](https://redis.io/)\nperfectly captured the zeitgeist, and found its way into everyone's stack\npractically overnight. A capture from late 2011 has Redis describing itself as\nan *advanced key-value store* and *data structure server*. Notably absent is\nthe word *database*.\n\nPrior to Redis, [memcached](https://memcached.org/) was that one indispensable\npiece of infrastructure running quietly on most web servers. In every deployment\nI've ever seen Memcached typically handles a variety of ad-hoc usages in addition\nto just caching, like locks, counters, rate-limits, stuff like that. So when\nRedis landed, the story at that time was something like \"memcached but way better\".\nRedis' name, **Re** mote **Di** ctionary **S** erver, emphasized that it was\na fast in-memory dictionary that could be used by all your services. In\naddition to blobs of bytes, Redis operated on a handful of tastefully-chosen\ndata-structures (linked-list, hash-table, set, sorted-set), which vastly\nexpanded the kinds of ad-hoc use-cases such a service could provide.\n\nI want to call attention to some of the specific design considerations that I think Redis nailed perfectly, and which were instrumental in its initial success:\n\nAdoption grew incredibly quickly and the project was, deservingly, a huge\nsuccess. At some point along the way, the ambitions of the project changed.\nRedis took up the mantle of being a *database*:\n\nSome features have been genuinely useful additions, such as `BZPOPMIN`\n\nadded in 5.0,\nwhich allows a blocking-pop to be performed on a sorted-set (very nice when\nusing sorted-sets as a priority queue). Others struck me as being extremely\nun-Redis-y, like ACLs. But mostly, there seems to be a desire to make Redis be\neverything for everyone. The addition of these features closely tracks the\n\"latest cool thing\" developers are talking about on HN over the last decade:\n\nThe problem with this mindset are two-fold. First, it ignores the factors that made Redis an indispensable part of everyone's stack in the first place. Redis was simple, the commands were orthogonal and tightly scoped, the protocol was clean, and it was conceptually coherent. Second, it ignores the fact that anyone who is serious about integrating full-text search / event stream processing / strong-consistency kv / time-series / vector storage is going to want the real thing, not some half-baked Redis module that inherits all of Redis' restrictions. Because, at the end of the day, the HA story on Redis is complicated. The persistence story is nuanced and there are important tradeoffs. The protocol pain and client fragmentation is a real hurdle. Redis does not aim to replace Postgres in your stack, and I would argue that ElasticSearch / RabbitMQ / etc / etc are similarly foundational pillars of any system.\n\nHere is a quote from Aphyr's analysis of the initial development build of Redis-Raft:\n\n...we found twenty-one issues, including long-lasting unavailability in healthy clusters, eight crashes, three cases of stale reads, one case of aborted reads, five bugs resulting in the loss of committed updates, one infinite loop, and two cases where logically corrupt responses could be sent to clients. The first version we tested (1b3fbf6) was essentially unusable...\n\nRedis the cache and data-structure server is a fundamentally different proposition from \"Redis the etcd\" or any of the other databases named above. This is the disconnect.\n\nWhen antirez announced [Disque](https://github.com/antirez/disque#readme) back\nin 2015, I wrote a short piece explaining [why I won't use it](http://charlesleifer.com/blog/why-i-won-t-be-switching-to-disque/).\nMy reasoning hinged on this comment by antirez:\n\nDisque was designed a bit in astronaut mode, not triggered by an actual use case of mine, but more in response to what I was seeing people doing with Redis as a message queue and with other message queues.\n\nI read that admission as being predictive of one outcome: abandonment. Projects developed in \"astronaut mode\", as personal challenges, as learning exercises are wonderful. Without a solid use-case, though, will the maintainer retain interest and focus in order to solve the long-tail of hard problems that crop up as soon as people start using it? While also maintaining Redis? HA message delivery is legitimately difficult to solve well, and whatever side of the CAP theorem you optimize for, you will be forced to make tradeoffs and solve some difficult problems.\n\nFurthermore, I believed nobody would adopt. There were many mature message brokers in 2015. People used Redis as a message broker because they were already using Redis and it was good enough and simple. The need wasn't for a new message broker, nor was the need for Redis to become a more complex message broker. The project misread why people use Redis as a broker in the first place. People use Redis as a message broker specifically because they don't want to use something else.\n\nI believe my predictions held true - Disque became abandonware almost as soon as it was announced, despite sitting at 8K stars on GitHub. Some time later it was rewritten as a Redis module, but that project is also sitting abandoned for the last 7 or 8 years.\n\nI want to be clear that none of this discussion should be taken as overt or\nimplied criticism of antirez. I have enormous respect for his talent and his\ntaste. The main force I see at work in the development of Redis is, as I\nmentioned in the beginning, ambition. The ambition of a developer to solve\ncomplex problems, the ambition to be everything to everyone, the ambition of\nRedis' landlords to find a way to extract maximum revenue before AWS and GCP\n[finish them off for good](https://valkey.io/). There is nothing inherently\nwrong with ambition. The problem is when the ambition leads you to lose sight\nof what made you successful in the first place.\n\nValkey's existence and adoption is the wider market's final verdict on this\ndynamic. Rather than chase features and [bullet points](https://redis.io/compare/valkey/),\nValkey has invested in the un-glamorous work of improving multi-threaded\nperformance, memory efficiency, cluster reliability and throughput. Valkey's\nperformance benchmarks are impressive and aimed squarely at the 80% of Redis\nusers who just want the same features Redis shipped with back in 2011. There's\nno need for a new array type in Valkey's world.", "url": "https://wpnews.pro/news/redis-and-the-cost-of-ambition", "canonical_source": "http://charlesleifer.com/blog/redis-and-the-cost-of-ambition/", "published_at": "2026-05-12 11:28:01+00:00", "updated_at": "2026-06-03 04:07:08.074751+00:00", "lang": "en", "topics": ["ai-tools"], "entities": ["antirez", "Redis"], "alternates": {"html": "https://wpnews.pro/news/redis-and-the-cost-of-ambition", "markdown": "https://wpnews.pro/news/redis-and-the-cost-of-ambition.md", "text": "https://wpnews.pro/news/redis-and-the-cost-of-ambition.txt", "jsonld": "https://wpnews.pro/news/redis-and-the-cost-of-ambition.jsonld"}}