Filtered Vector Search (FVS) is critical for supporting semantic search and GenAI applications in modern database systems. However, existing research most often evaluates algorithms in specialized libraries, making optimistic assumptions that do not align with enterprise-grade database systems. Our work challenges this premise by demonstrating that in a production-grade database system, commonly made assumptions do not hold, leading to performance characteristics and algorithmic trade-offs that are fundamentally different from those observed in isolated library settings. This paper presents the first in-depth analysis of filter-agnostic FVS algorithms within a production PostgreSQL-compatible system. We systematically evaluate post-filtering and inline-filtering strategies across a wide range of selectivities and correlations. Our central finding is that the optimal algorithm is not dictated by the cost of distance computations alone, but that system-level overheads that come from both distance computations and filter operations (like page accesses and data retrieval) play a significant role. We demonstrate that graph-based approaches (such as NaviX/ACORN) can incur prohibitive numbers of filter checks and system-level overheads, compared with clustering-based indexes such as ScaNN, often canceling out their theoretical benefits in real-world database environments. Ultimately, our findings provide the database community with crucial insights and practical guidelines, demonstrating that the optimal choice for a filter-agnostic FVS algorithm is not absolute, but rather a system-aware decision contingent on the interplay between workload characteristics and the underlying costs of data access in a real-world database architecture.
Figures & tables
Figure 1. Average latency for 100 filtered vector search queries on OpenAI-1M: HNSWLib (solid) vs. PGVector (dashed). System latency can be up to 10× higher, and the gap varies with selectivity, motivating an in-depth comparison of FVS algorithms in a real DBMS.
Arch. Aspect
Library
System (PGVector)
System overheads
Index Storage
Compact representation: Neighbors stored as raw pointers. Nodes are packed contiguously with no alignment constraints.
Tuple-based storage: Each neighbor reference is a 6-byte TID. Nodes are stored as tuples, with header overhead, in 8KB pages.
Direct deference: The neighbor access is a CPU-level memory dereference.
Scattered page access: The neighbors are stored as TIDs pointing to arbitrary pages.
Random I/O amplification: Each hop multiplies page overhead by neighbor fanout.
Filter Evaluation
Unified identifier: A single ID/offset indexes both vector data and attribute data in memory.
Indirection: Index page → HeapTID → Heap page. Filter columns reside in the heap. Evaluating predicates needs HeapTID.
Double lookup: Every filtered candidate requires: (1) index access for vector+HeapTID, (2) heap access for filter columns.
Parallelism
Flexible: Intra-query parallelism via OpenMP, std::thread , or SIMD.
Constrained: One query per connection. No batch query primitive.
Arch. limit: Executor/storage hinders fine-grained parallelism and batching.
Table 1. System breakdown for HNSW: architectural differences between standalone libraries and database systems.
Figure 2. Execution strategies for an FVS query.
Figure 3. Filter-first execution methods for an FVS query.
Figure 4. Traversal-first execution methods for an FVS query.
Figure 5. Execution methods for an FVS query on ScaNN.
Figure 6. NaviX, ACORN, Sweeping, and Iterative Scan implementations in PGVector.
Figure 7. Filtered ScaNN implementation in the system.
Figure 8. Illustration of the filter generator methodology. A Positive Correlation workload is then generated by preferentially sampling vectors from the closest neighbors, conversely, for the Negative Correlation.
Dataset
# Vec
Dims
Metric
Source
Dist.-Filt. Rel. Cost
LID/LRC
sift10M ( Jégou et al., 2011 )
10M
128
L2
Image Descriptors
0.8x
19.11/0.82
openai5M ( , 2025 )
5M
1536
IP
Text Embeddings
6x
33.34/0.97
cohere10M ( , 2022 )
10M
768
L2
Text Embeddings
3.3x
38.63/0.97
text2image10M ( Simhadri et al., 2022 )
10M
200
L2
Multimodal Emb.
1.3x
52.47/0.98
Table 2. Comparison and characteristics of benchmark datasets.
Time (min)
Size (GB)
Dataset
HNSW
ScaNN
HNSW
ScaNN
sift10M
24.80
1.87
9.58
1.73
openai5M
49.10
10.36
38.15
1.89
cohere10M
72.83
18.24
38.14
1.95
text2image10M
20.35
2.84
12.72
2.35
Table 3. Index build time and size comparison.
Dataset
Method
QPS
Index Size
Build Time
sift10M
Halfvec
0.97 ×
1.34 ×
1.01 ×
BQ+rerank
–*
2.00 ×
1.02 ×
openai5M
Halfvec
1.03 ×
2.00 ×
1.11 ×
BQ+rerank
0.75 ×
11.63 ×
2.86 ×
cohere10M
Halfvec
1.04 ×
2.00 ×
1.24 ×
BQ+rerank
0.96 ×
11.83 ×
2.33 ×
Table 4. QPS speedup and reduction in index size and build time of 1,000 unfiltered vector search queries in PGVector-HNSW with 16 threads (Microbenchmark 95% Recall@10).
Dataset
Method
1% sel.
5% sel.
20% sel.
50% sel.
80% sel.
sift10M
Quant.
1.40 ×
1.42 ×
1.56 ×
1.49 ×
1.58 ×
openai5M
PCA
29.39 ×
5.79 ×
3.92 ×
3.22 ×
3.62 ×
PCA+Quant.
50.21 ×
8.61 ×
6.06 ×
5.02 ×
5.17 ×
cohere10M
PCA
5.24 ×
4.47 ×
3.48 ×
3.76 ×
3.83 ×
PCA+Quant.
9.60 ×
7.27 ×
6.55 ×
6.48 ×
5.52 ×
text2image10M
Quant.
2.17 ×
1.51 ×
1.45 ×
1.87 ×
1.79 ×
Table 5. Latency speedup of different settings w.r.t. non-quantized non-PCAed ScaNN on 95% recall@10 with 16 threads (no correlation). Columns show increasing selectivity. Quantization uses SQ8.
Figure 9. QPS at 95% Recall@10 for methods across various selectivities on four datasets with no vector-predicate correlation.
Distance Computations
Filter Checks
Hops / (Leaves & Reordering)
Page Access
Sel.
NaviX
ACORN
Sweep.
ScaNN
NaviX
ACORN
Sweep.
ScaNN
NaviX
ACORN
Sweep.
ScaNN
NaviX
ACORN
Sweep.
ScaNN
1%
246
238
23.0K
1.4K
71.8K
71.6K
2.6K
143.9K
17.8
17.7
1.1K
150/62
1.2K
1.2K
24.0K
4.5K
2%
357
408
9.4K
1.9K
66.6K
59.6K
1.4K
96.0K
19.8
20.9
398
100/60
1.5K
1.6K
9.8K
3.2K
5%
627
614
5.0K
3.8K
36.2K
34.9K
910
76.9K
13.0
23.0
197
80/60
1.1K
1.4K
5.2K
2.8K
10%
886
1.1K
3.3K
4.8K
24.5K
40.4K
359
48.2K
12.8
21.9
107
50/95
1.2K
1.9K
3.4K
2.2K
20%
1.2K
1.2K
2.2K
9.7K
12.6K
14.6K
219
48.2K
13.2
32.3
64.3
50/80
1.4K
1.8K
2.3K
2.1K
Table 6. Breakdown of internal index statistics across varying selectivities on OpenAI-5M (no correlation). Colors indicate relative performance within each metric group (green=lower/better, red=higher/worse). Bold indicates the best value per row.
Figure 10. Latency breakdown (CPU cycles) of a query running for 1, 10, 50, and 80% selectivities on the OpenAI-5M dataset without correlation. Bars (1% sel. for Sweeping) are clipped at the plot’s y-axis limit for readability; annotations “True: X” report the full (unclipped) cycle count.
Figure 11. Varying LIMIT k on all datasets (no correlation).
Figure 12. QPS v.s. Selectivity on OpenAI-5M, showing how vector-predicate correlation alters the performance and crossover point of each FVS algorithm.
Figure 13. Latency breakdowns with/without a translation map on the OpenAI-5M dataset (no correlation).
Method
Threads
Total Cycles
SysOH%
DistComp%
Filter%
NaviX
1T
24.1M
55.9%
13.0%
12.3%
NaviX
16T
35.6M (+48%)
73.5%
7.5%
9.5%
Sweep.
1T
45.0M
81.8%
18.6%
0.2%
Sweep.
16T
75.7M (+68%)
91.0%
11.9%
0.2%
ScaNN
1T
20.7M
84.4%
3.1%
12.5%
ScaNN
16T
32.9M (+59%)
86.9%
2.5%
10.5%
Table 7. Comparison of average CPU cycles breakdown between single- v.s. multiple- threads (1T v.s. 16T) at 10% selectivity on OpenAI-5M with 95% recall@10 (no correlation).
Vector databases are increasingly used in security sensitive contexts with Retrieval Augmented Generation and organizational AI pipelines; however, their security capabilities remain limited. Specifically, Fine-grained Access Control (FGAC) which is required to ensure that data access adheres to user-specific policies is not fully supported in modern vector databases. Unlike relational databases, vector databases combine structured and unstructured attributes to provide semantic, approximate query results, which complicates FGAC implementation. This creates an inherent tension between enforcing FGAC policies correctly, achieving high ANN search recall and maintaining low query latency. In this paper, we present a vision for Policy-aware Vector Search by formalizing the FGAC policy model in vector databases as well as the enforcement problem. We compare various enforcement strategies, present preliminary findings, and identify key open challenges for future research in policy-aware vector search.
A fundamental challenge of vector search is achieving consistently high recall while minimizing computational costs. Fixed search parameters cause significant performance variance across queries, and conventional evaluation on average recall masks these per-query disparities. We introduce QASP (Query-Adaptive robust vector Search Policy), which predicts the complete recall progression curve per query via a single upfront supervised regression, from which a search policy is derived for any recall target; this avoids iterative model invocations during search or separate predictors per target. By predicting normalized recall values with scale-invariant features and pre-search inference, QASP generalizes across recall targets, index configurations, and datasets. The fine-grained progress predictions further enable a lightweight reactive complement that adjusts search depth based on predicted-versus-observed deviations without additional inference. We prove that QASP requires a finite training sample independent of dataset size and dimensionality, that it matches or improves on the best fixed-policy loss up to a vanishing statistical error, and that its data access savings over fixed probing grow exponentially in intrinsic dimensionality. Experimentally, QASP achieves significantly lower recall variance and deviation from target, higher query satisfaction rate, and scales to large data and hierarchical indices without retraining, achieving 99% recall with 80% less data access. Our implementation can be found at https://github.com/amazon-science/QASP.
Hakan Ferhatosmanoglu, Kushal Kumar, Tal Wagner +1
Amazon, London, UK · Amazon, New York, USA · Amazon and Tel-Aviv University, Tel Aviv, Israel +1
Retrieval-Augmented Generation (RAG) systems increasingly power enterprise LLM applications, yet the vector retrieval layer introduces two underexplored challenges: (1) trained codebook quantizers may expose corpus statistics during index construction, creating a leakage channel in multi-tenant deployments, and (2) post-hoc filtering for tenant isolation degrades recall on selective queries. We study TurboVec, an open-source vector index built on TurboQuant - a codebook-oblivious scalar quantizer requiring no corpus-dependent training. On the DBpedia OpenAI embeddings benchmark (d=1536, 100K-999K vectors), TurboQuant 4-bit outperforms trained FAISS Product Quantization at the same memory budget by 8.5-8.9 percentage points in Recall@5 across all scales. Compared to HNSW (R@5=0.991) and IVF-PQ (R@5=0.840), TurboQuant occupies a distinct design point: higher recall than IVF-PQ without training, at 4-8x less memory than HNSW. Deployed on Snowpark Container Services, TurboVec achieves 11ms median query latency at 100K vectors versus 707ms for warehouse brute-force scan. Kernel-level allowlist filtering maintains 0.86-0.93 Recall@10 across 10-1000 tenant workloads versus 0.09-0.19 for post-filter baselines. Codebook-oblivious design reduces membership inference accuracy to near-random (50.0%) versus 57.3% for PQ codebooks. Limitations include single dataset evaluation, uncompressed HNSW comparison, and privacy evaluation on synthetic data only.
Navnit Shukla, Kamal Pandey, Omsankar Tiwari
Snowflake Inc. Tustin, California, USA · Rivian Automotive Inc. Irvine, United States of America · Google Deepmind Sunnyvale, California, USA