Filtered vector search in Postgres creates a fundamental tension between recall and performance because ANN indexes (HNSW, IVFFlat) and WHERE clauses cannot be intersected like B-trees. The post explains why this happens and covers four practical patterns: pgvector iterative index scans (with tuning for max_scan_tuples, ef_search, and strict vs relaxed ordering), partial HNSW indexes for stable low-cardinality filters, oversampling with a pool_size formula derived from pg_stats selectivity estimates, and caching hybrid query results in a Postgres lookup table. A decision guide maps each pattern to the right use case, and EXPLAIN output examples help diagnose which plan the planner actually chose.
Table of contents
When nearest neighbor meets a WHERE clausepgvector iterative index scansWorkarounds and TricksDiagnosing plan choice with EXPLAINChoosing a workaround638 Impressions