ACORN moves the filter into the HNSW graph walk with predicate subgraph traversal

Pre-filtering and post-filtering fail on different parameters, and which one you run decides whether ACORN's headline number could be yours. Pre-filtering, in the paper's account, finds every record that passes the predicate and then runs brute force similarity search over that set. The authors say it scales poorly and becomes inefficient for medium to high selectivity predicates on large datasets ^[9].

Post-filtering breaks in the other direction. It searches the ANN index first and drops the results that fail the predicate, and because the vectors nearest the query may not pass, the scope of the search has to expand. The paper says that expansion is expensive for predicates with low selectivity or low correlation to the query vector, and it names Milvus, Weaviate and AnalyticDB-V among the systems it discusses ^[10][11].

Predicate subgraph traversal is offered as an emulation of a theoretically ideal but impractical hybrid search strategy ^[3]. The construction algorithm is predicate-agnostic, so the graph is built without reference to the filters it will later serve, and the abstract says that construction is what makes the traversal effective across a wide array of predicate sets and query semantics ^[4]. The filter is applied during the walk.

The reported gain is 2 to 1,000 times higher throughput than prior methods at a fixed recall ^[6]. The ends of that range differ by a factor of 500 ^[14]. Both ends cannot describe the same workload. For the high end to be yours, your predicates would have to sit where the paper puts post-filtering's worst case, at low selectivity or low correlation with the query vector ^[10]. A few equality predicates over a low-cardinality attribute puts you in the regime the paper says specialized data structures already cover ^[8], and predicate sets like those are what it inherits from prior benchmarks ^[5].

For a team already running HNSW, the operative sentence is that ACORN can be implemented efficiently by extending existing HNSW libraries ^[2]. No second index for the filters, and no new service to run. What you carry instead is a patched library and its rebases. The supplied text of the paper stops mid-sentence in the introduction, so the evaluation setup, build costs and the per-dataset split of that throughput range are not in it ^[15].

The case against specialized engines is the paper's own: it argues proposed hybrid methods either suffer poor performance or support a severely restricted set of search predicates, for instance only small sets of equality predicates ^[7]. Against that it sets predicates that are not known in advance, including user-entered keywords, range searches and regex matching ^[12]. No per-predicate structure enumerates those at build time. One of the paper's worked examples is a data scientist retrieving images that look similar to a reference dog but carry the label cat ^[13].