Why pgvector similarity search is slow, and how to fix it without leaving Postgres

Without an HNSW or IVFFlat index, pgvector falls back to a brute-force sequential scan that computes distance against every row in the table. This works fine for a few thousand rows but scales linearly and becomes unacceptably slow once the table reaches tens or hundreds of thousands of rows.

Fix: Create an appropriate index: an HNSW index with vector_cosine_ops is the best default choice, or an IVFFlat index with lists set to roughly the square root of the row count.

CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);
EXPLAIN ANALYZE SELECT id FROM items ORDER BY embedding <=> '[...]' LIMIT 10;

pgvector indexes are built for a specific operator class: vector_l2_ops for Euclidean distance, vector_cosine_ops for cosine distance, and vector_ip_ops for inner product. If the index was built with one operator class but the query uses a different operator, Postgres cannot use that index for the query and silently falls back to a sequential scan with no error message.

Fix: Check the index definition and confirm the operator class matches the operator used in ORDER BY; if it does not, drop and rebuild the index with the correct operator class rather than changing the query, since the operator class should match the distance metric your embeddings were normalized for.

SELECT indexdef FROM pg_indexes WHERE tablename = 'items';

HNSW's ef_search and IVFFlat's probes control the search-time speed/recall tradeoff. Low default values prioritize speed over recall, which can look like slow queries when what is actually happening is fast-but-wrong results that require the application layer to retry or over-fetch to compensate.

Fix: Increase ef_search (HNSW) or probes (IVFFlat) incrementally and measure both latency and recall against a labeled test set to find the setting that meets your recall target without unnecessary latency.

SET hnsw.ef_search = 100;
SET ivfflat.probes = 10;

Postgres does not immediately reclaim space from updated or deleted rows; dead tuples accumulate and both sequential scans and, to a lesser extent, index scans have to skip over them, adding overhead that grows with churn and shows up as gradually worsening query times.

Fix: Run VACUUM ANALYZE regularly on high-churn vector tables, and consider more aggressive autovacuum settings for that table specifically if updates are frequent.

VACUUM ANALYZE items;

Building an HNSW index is memory-intensive; if maintenance_work_mem is too low, Postgres has to spill graph-building work to disk, which can make index creation extremely slow or, in constrained environments, fail outright partway through.

Fix: Raise maintenance_work_mem for the session running CREATE INDEX, then reset it afterward if it was raised globally.

SET maintenance_work_mem = '2GB';
CREATE INDEX ON items USING hnsw (embedding vector_cosine_ops);