HNSW doesn't always scale? (daily search tip)


In previous tips I talked about tail latency

  • Your search cluster becomes as slow as the slowest node
  • A wide per-node latency distribution results in an even wider per-cluster distribution

The higher the scale, the more sharded your data becomes, the more small node latency problems exaggerate cluster latencies.

So when I think about graph-based vector retrieval at scale, like HNSW, I get nervous.

With HNSW you’re:

  • Navigating a non-deterministic graph, depending on the order graph is constructed
  • Constructed from a non-deterministic set of points specific to this node
  • Jumping around to different areas of memory, destroying any memory locality

All the non-determinism here worries me. Some nodes will quickly converge on nearest neighbors. Other nodes will take more work.

The cluster’s latency becomes the latency of those nodes that take more work.

Since benchmarks like ANN benchmarks all happen in nicely warmed memory, on one system, they’ll miss these issues.

So search carefully and measure your cluster behavior, not just single node behavior!

-Doug

Events · Consulting · Training (use code search-tips)

You're subscribed to Doug Turnbull's daily search tips where I share tips, blog articles, events, and more. You can always manage your profile:

Doug Turnbull

I share search tips, blog articles, and free events I'm hosting about the search+retreval industry, vector databases, information retrieval and more.

Read more from Doug Turnbull

My work is split between mature search teams and new AI teams. Search teams are often farther along and manage a mature, traditional search product. AI teams, however, often don't know what they don't know yet. They've just been cobbled together, have built a few agent demos, and are often in the process of discovering the three big mistakes I blog here: Evals+measurement need to dominate a lot of your product thinking Retrieval isn't "one thing" (ie classic RAG) - its extremely custom to...

I'm writing about the weak spots in vector databases. Where you should prod and poke when selecting a vendor. Today: Updating Vector Databases If you think about the old vector search regime, it involved Indexing everything up front Never updating the index Search-only We overindexed on this paradigm, creating data structures focused on good search performance that couldn't tolerate updates. I wrote about how sensitive graph-based vector DBs in particular are to updates, picking on Lucene...

Hey all, I wrote a new article about a technique that has come up over and over in my work, especially in my Cheat at Search training, for doing effective query understanding into a large vocabulary. Instead of asking an LLM to classify into a vocabulary. Ask it to hallucinate fake entities, then resolve those to real ones client side. Save yourself a lot of tokens and use cheaper models. https://softwaredoug.com/blog/2026/08/10/hypothetical-classifications -Doug PS - A reminder that Vectors...