# Redis and the Cost of Ambition

[[charles-leifer-blog|Charles Leifer]]'s 2026 piece prompted by skimming antirez's PR to add an *array* type to Redis. The PR's rationale — hashes need a key for lookup, lists hide the middle, streams are append-only — is fine as a local justification, but Leifer reads the broader context and asks: "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?"

The answer is the title — *ambition*. Redis began as a tightly-scoped in-memory data-structure server, kept accreting features to be everything to everyone, and lost the property that made it indispensable. The current crisis is downstream of two decades of trying to be more.

## The 2026 crisis surface

Leifer enumerates the recent inflammation:

- **Licensing.** Redis Inc dropped BSD in 2024, the community revolted, the company called a strategic retreat to tri-licensing with AGPLv3 as the only OSI option. AGPL lets Redis Inc say "open source"; AGPL ≠ BSD in any operational sense.
- **The Garantia Data backstory.** The VC-backed company behind Redis began as Garantia Data, a NoSQL hosting service; got into Redis hosting; rebranded; signed antirez to legitimise themselves; eventually took over the trademark — setting up the 2024 rugpull.
- **Bloat and lock-in.** The feature set grew (and grew) to include exotic data structures, complex stateful systems (streams), semi-proprietary modules.
- **Positioning drift.** Redis's 2026 landing page calls it *The Real-Time Context Engine for AI Apps*, alongside "Try Redis for Free" and the enterprise-sales "Get a Demo" CTAs.
- **The "we are too a web-scale database" arc.** Sentinel, Cluster, Redis-Raft, active-active geo-distribution®, Redis Flex®, Redis-on-Flash®.
- **RESP3.** Leifer reads it as a classic Brooks second-system effect — break the request/reply assumption underpinning RESP2.
- **Client-side caching as a protocol feature.** A reductio-ad-absurdum: Redis (lately the *cache*) now needs a new protocol to support caching on the *client* side as well.

## What Redis nailed in 2011

Leifer's frame is that ambition cost Redis the three things that made it irreplaceable:

- **The wire protocol.** Simple enough to read and implement in an hour, expressive enough to ship real data types. Building a Redis client is unusually pleasant. Leifer's own most popular post — building a simple Redis server in Python — works because the protocol *invites* the exercise.
- **Single-threaded, event-driven, in-memory.** These three go together: single-threaded makes operations atomic full-stop (no locking, no contention reasoning). Single-threaded requires non-blocking I/O. In-memory keeps operations fast enough that a single thread can serve a high client count. Pull any one of these and the design collapses; together they're coherent.
- **The data structures.** Linked-list, hash-table, set, sorted-set, strings. Each covered a real use case (queue, structured record, dedup set, leaderboard, cached value). The primitives were *tasteful*. The handful was enough.

## The "ambition" trajectory

Leifer traces the feature additions and notices a pattern — each major feature lines up with what HN was excited about at the time:

- MongoDB → Redis as a [document database](https://redis.io/docs/latest/develop/data-types/json/)
- ElasticSearch → Redis as a [search engine](https://redis.io/docs/latest/develop/ai/search-and-query/)
- Graph databases → RedisGraph... [which was then EOL'd](https://redis.io/blog/redisgraph-eol/)
- Kafka → [Streams](https://redis.io/docs/latest/develop/data-types/streams/)
- ZooKeeper / strong consistency → [Redis-Raft](https://redis.io/blog/redisraft-new-strong-consistency-deployment-option/)
- InfluxDB → [Time-series](https://redis.io/docs/latest/develop/data-types/timeseries/)
- AI → [Vector sets](https://redis.io/docs/latest/develop/data-types/vector-sets/)

Two failure modes from this:

1. **Forgetting why Redis won.** Simple, orthogonal, conceptually coherent. The accreted modules don't share that property.
2. **Half-baked alternatives lose to real ones.** Anyone serious about full-text search, event streaming, strong consistency, time-series, or vector storage will pick the dedicated system, not the Redis module that inherits Redis's HA / persistence / protocol-pain tradeoffs.

Aphyr's analysis of the initial Redis-Raft (1b3fbf6) lives as a permanent example: *"twenty-one issues, including long-lasting unavailability in healthy clusters, eight crashes, three cases of stale reads ... essentially unusable."*

## The Disque tell

Leifer pulls in a 2015 prediction he made. When antirez announced [Disque](https://github.com/antirez/disque#readme) (Redis-flavoured message broker), antirez said: *"Disque 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."*

Leifer read that as predicting abandonment, and explained at the time why nobody would adopt: there were many mature message brokers in 2015; people used Redis-as-broker *because they were already using Redis*; the need wasn't for a new broker, it was for Redis to stay Redis. Disque misread its own demand.

The prediction held — Disque has been abandonware since shortly after announcement (8K stars and idle), the Redis-module rewrite is also dormant. "Astronaut mode" is Leifer's named pattern: features developed as personal challenges or learning exercises, without an actual use case to anchor the long tail of hard problems.

## Where the energy went

Leifer is explicit that this isn't a criticism of antirez personally — he has "enormous respect for his talent and his taste." The main forces are structural:

- Developer ambition to solve interesting problems.
- The ambition to be everything to everyone.
- The ambition of Redis's *landlords* to extract maximum revenue before AWS and GCP (via [Valkey](https://valkey.io/)) finish them off.

## Valkey as the verdict

Valkey's existence and adoption is the market's reply. Rather than chase feature bullet points ([Redis vs Valkey comparison page](https://redis.io/compare/valkey/)), Valkey invested in *unglamorous* work — multi-threaded performance, memory efficiency, cluster reliability and throughput. The benchmarks aim squarely at "the 80% of Redis users who just want what Redis shipped in 2011." Leifer's closer: *"There's no need for a new array type in Valkey's world."*

## Where it fits

- **[[no-silver-bullet-llms]] / [[no-silver-bullet]]** — Brooks' essential-vs-accidental difficulty. Redis's accidental-difficulty surface grew without bound; the essential difficulty (data caching, ad-hoc concurrency primitives for web apps) hasn't moved. The accretion runs against Brooks.
- **[[ceo-ai-psychosis]] / [[ai-great-leap-forward]]** — metric-driven feature production in another setting. The 2026 Redis landing page calling itself *The Real-Time Context Engine for AI Apps* is the [[tokenmaxxing]] of database categories.
- **[[duckdb-quack-protocol]]** is the *opposite* trajectory in the database space — an in-process-first system carefully adding one wire protocol because the workaround zoo was getting bigger than the protocol would be. The DuckDB team's published rationale ("we want format-control freedom; we picked HTTP for the ecosystem") is what considered protocol design looks like when the constraints are honest. RESP3 didn't have those constraints.
- **[[best-polished-version-strategy]]** — Valkey is the "best polished version" of Redis-the-cache, working precisely because the original tool became bad enough (licence drama, RESP3, AI-positioning) to overcome switching cost. Same dynamic as Linear-for-Jira.
- **[[supply-chain-security]]** — the licence-rugpull part of the Redis story is a different shape of supply-chain trust failure; the trademark capture by Garantia / Redis Inc is the structural mechanism several wiki pages now name without naming Redis. This page makes the canonical reference concrete.

## Quotes worth keeping

> The problem is when the ambition leads you to lose sight of what made you successful in the first place.

> People use Redis as a message broker specifically because they don't want to use something else.

## Related

- [[antirez]] — Salvatore Sanfilippo's entity page; the same person whose feature choices this analysis reads as ambition-driven bloat.
- [[control-the-ideas-not-the-code]] — antirez's own July 2026 argument that experienced programmers should hold the design and stop reviewing LLM code line by line; he treats routine data-structure PRs as taste-driven maintenance, not feature creep.