I have been hacking away at Semhub. The search experience has got to be fast, good, and consistent, and the current iteration ain’t that.

To summarise: the current search routes the query based on how many issues it’s searching across:

• If the filter is highly selective, we don’t use the HNSW index and directly filter and compare vectors, which is fast (~3-5s) but relies on sequential scans, making it computationally expensive and hard to scale.
• If the filter is not thattt selective (i.e. it searches across sufficiently many issues), we use HNSW indexing with iterative scans to ensure enough results are retrieved before filtering. While scalable, this approach suffers from degraded recall and variable latency as the dataset grows.

Relying on sequential scan feels wrong, much like the larger architecture of this “route-based” search. Filtering with vector search is a burgeoning field and there is no clearly correct answer to this challenge (alternatives include using pgvectorscale or spinning up a dedicated vector database…)

In any case, it’s Sunday and I shall take a break. I came across this and my takeaway is: I ain’t afraid of nothin’.