In praise of memcached

Original Article ↗ Hacker News Discussion ↗

Memcached’s minimalist, in‑memory key–value design is being contrasted with Redis/Valkey’s richer feature set, which blends caching with persistent data structures, clustering and advanced data types. Commenters argue that Redis’ flexibility often leads teams to misuse it as a primary database or build fragile systems that assume persistence and perfect uptime, whereas memcached’s strict ephemerality can enforce safer “cache-only” patterns but comes with its own operational quirks. Many conclude that the right choice depends on context: small or simple systems can often lean on the primary database or a basic cache, while larger architectures must weigh performance, complexity, cost of RAM, and the risk of over‑engineering their caching layer.

AI-written accusations and meta-discussion

  • Several commenters object to the reflexive “this is AI-written” claim, calling it low-value and now common on HN.
  • Others think the article “reads like AI” or was at least polished by an LLM, but there’s no consensus or proof, and some point to specific informal phrasing as unlikely from an LLM.

Redis vs Memcached as cache technologies

  • Many agree Redis works well as a cache but needs careful configuration: enforce expiries, disable or separate persistence, set maxmemory and eviction policy, and avoid complex structures for cached objects.
  • A major theme: Redis tries to be both persistent store and volatile cache; that duality makes misuse easy (e.g., treating it as durable DB, forgetting eviction).
  • Memcached is praised as “boring,” simple, purely ephemeral, and harder to misuse as storage. Its lack of clustering and features is seen as a virtue by some and a limitation by others.

Operational issues and failure modes

  • Reported Redis/Valkey incidents: no eviction leading to OOM, AOF write failures due to disk full, applications assuming Redis is always up and populated with no fallback.
  • Some like memcached’s “fail open” model (null on failure → recompute), others think silent failure is dangerous and prefer explicit errors.
  • Memcached slab allocation can cause “slab starvation” and needs tuning; this is cited as a hidden complexity.

Performance, complexity, and alternatives

  • Claims that memcached is significantly faster for simple KV; counterclaims say real-world differences can be small and network latency dominates.
  • Some argue an RDBMS (e.g., Postgres/MariaDB) with its own cache is enough for most workloads; others note Redis is simpler than a full DB and excels when colocated.
  • Single-threaded Redis vs multithreaded memcached is debated; Redis can stall on complex operations, while memcached targets O(1) ops by design.

Broader use cases and ecosystem drift

  • Redis is used beyond caching: rate limiting, feature flags, pub/sub, WebSocket backplanes, job queues, coordination for distributed tasks.
  • Some prefer separating concerns: memcached (or DB+filesystem) for caching, Redis with persistence for data-structure-heavy features.
  • There is criticism of Redis’ feature creep and marketing (including AI positioning) and mention of Valkey and other systems, but no clear consensus that one tool “wins” overall.