You might not need Redis

Original Article ↗ Hacker News Discussion ↗

Redis’ Reputation and Perceived Quality

  • Strong praise for core Redis as “magnificently written” and extremely solid; some single servers run huge QPS for long uptimes.
  • Counterpoint: in some companies Redis is outright banned after outages, especially around Sentinel/cluster and replication.
  • Redis Search is called buggy; core server generally respected, but client libraries and distributed usage have caused CVEs and bad experiences.
  • Main concern is less the API and more the operational hazards and misuse.

When Redis Is the Right Tool

  • Well-suited for high-velocity, weakly-durable data: counters, feeds, chat, rate limiting, leaderboards, matchmaking, sessions, TTL caches.
  • Valued as a “data structure server”: lists, sets, sorted sets, bitmaps, probabilistic structures (Bloom, HyperLogLog, Top-K, etc.), streams and queues.
  • Very handy when many services in different languages must share state or data structures.

Overuse, Premature Optimization, and Simpler Alternatives

  • Many comments say most apps (especially far below tens of thousands of QPS) can just use MySQL/Postgres with good indexing, or even SQLite.
  • Local in-process caches (hashmaps, Caffeine/Guava, etc.) are often faster and simpler than a networked Redis, if data isn’t shared across nodes.
  • Memcached is preferred by some for simple KV caching because it’s constrained in scope and operationally simpler.
  • Several note that people copy FAANG-style stacks (Redis, Kafka, Elastic, NoSQL) at tiny scales, adding complexity for no benefit.

Redis as Persistent / Transactional Store: Warnings

  • Multiple reports of pain using Redis as a durable datastore: Sentinel/cluster flakiness, replication breakage, outages.
  • Skepticism about using it for transactional or “active-active” scenarios; documentation on conflict resolution and distributed locks seen as weak.
  • Several teams now use Redis strictly as ephemeral cache or buffer; design rule: the system must survive a full cache flush.

Anecdotes and Broader Lessons

  • High-profile pricing/geo systems were massively over-built on Redis, then successfully replaced by algorithms on a single machine plus Elasticsearch or DB features.
  • Horror stories of people building ad-hoc relational schemas inside Redis instead of using a real database.
  • Theme that adding any new datastore brings nontrivial cost in management, scaling, backup, and incident risk.
  • Broader critique: industry often follows infrastructure fads (Redis, NoSQL) instead of carefully reasoning about the actual performance problem.