November 11, 2025
Graph beef, thread relief
Scaling HNSWs
Redis chases speed; commenters battle over graphs, filters, and a lost Mac tale
TLDR: Redis’s creator shared advanced lessons on a new fast vector search feature and even used threads in a usually single-threaded system. Comments erupted over whether graphs scale, how to filter results, and a missing blog post saga—highlighting real-world needs and tradeoffs.
The Redis creator just dropped an “extra mile” brain dump on HNSW (Hierarchical Navigable Small World—a graph trick for fast-ish similarity search) and the crowd went full popcorn. He added real deletions, questioned whether the “hierarchy” is even needed, and—gasp—used threads in a system famous for being single-threaded to keep things fast. Memory bloat, pointer compression, and speed-vs-space tradeoffs? All on the table. But the comments turned it into a street fight over what actually matters in the real world.
The loudest chorus: filters or bust. One commenter warned that at huge scale teams ditch complex graphs or layer clustering on top, because graph pointers aren’t cache-friendly and people “almost always want to filter” results. Another cheered the transparency vibe—show devs the data structure so they can tailor it—while Wikipedia links flew to onboard the curious. The biggest gasp came from the threading reveal, with readers nodding that breaking the single-thread rule was worth it. And yes, the community demanded the missing MacOS mishap saga—“Mac ate my homework” memes everywhere. Under the snark, the message is clear: give us fast vector search that plays nice with filtering, and don’t hide the tradeoffs behind magic. The rest is nerd chess—and delicious drama.
Key Points
- •A new Redis type for vector similarity based on HNSW is stable, prompting a blog post of advanced findings.
- •The author extended HNSW to support actual deletions, addressing a gap in the original paper’s tombstone-only approach.
- •There are ongoing explorations into whether HNSW’s hierarchy is necessary, with ideas for flat structures or modified level selection thresholds.
- •In-memory scaling challenges include many neighbor pointers per node, multiple levels, and large float vectors (300–3000 components).
- •Pointer compression is a potential memory optimization but not yet implemented due to space–time performance tradeoffs in Redis.