pgvector, vector search inside the database you already run

It lives in Postgres, so your vectors sit next to your rows. One backup, one access-control model, one thing that pages you at 3am instead of two. You can join a similarity search against a permissions table in a single query, which is exactly the shape of a forward deployed problem: the client's data has tenancy rules and you cannot ship a system that quietly ignores them. Six distance operators cover every embedding model we have seen in the wild, including L2, inner product, cosine, Hamming and Jaccard. Two index types let you choose your pain: HNSW for query speed, IVFFlat for build speed. Half-precision and binary vectors cut index memory when the corpus grows. Dimensions go to 16,000, which is more than anything you will use. And for a client already on Postgres, the adoption cost is a CREATE EXTENSION and a migration. No procurement, no vendor security review, no new thing for someone to say no to. That last point wins more deployment arguments than any benchmark ever has.

Filtering. The documentation states it plainly: filtering is applied after the index is scanned. So a query that says WHERE tenant_id = $1 ORDER BY embedding <=> $2 LIMIT 10 can quietly return three rows instead of ten, because the approximate scan surfaced candidates belonging to other tenants and the filter then ate them. That is not a caveat. That is a wrong answer wearing the costume of a right one, and it is the single most common way we see pgvector deployments fail a review. You work around it with partial indexes per tenant, or by raising hnsw.ef_search, and both are tuning work that you own forever after. HNSW index builds want the graph to fit inside maintenance_work_mem, so on a real corpus you are sizing memory before you can index. Vacuuming HNSW indexes is slow. And there is no keyword search in the box, so hybrid retrieval means bolting on tsvector or an external BM25 and fusing the ranks yourself.

Spend an hour on pgvector if the client already runs Postgres and the corpus is under a few million chunks. That describes most first deployments. Skip it if you need billion-scale vectors, single-digit millisecond latency under heavy concurrent writes, or hybrid search without assembling it, because a dedicated vector store earns its extra moving part there. If you have never tuned a Postgres index, budget a second hour for ef_search and maintenance_work_mem before you trust the numbers.

Qdrant or Weaviate when scale or hybrid search genuinely justifies operating a second system. Otherwise stay in Postgres.