Rerankers can improve answer quality, but they cannot recover evidence that retrieval never found. Use them after recall, cost, and latency are understood.
PostgreSQL Topic Archive
pgvector and RAG PostgreSQL Articles
HNSW, IVFFlat, recall, embedding search, and production RAG performance notes.
HNSW defaults can look fast while missing useful results. Production tuning needs recall@k, p99, index build time, memory, and filtered result count together.
A fast RAG system can still be wrong. Production teams need recall@k, MRR, answerability, citation coverage, freshness, no-hit rate, and drift signals.
A RAG system is unsafe if deleted documents, permission changes, and stale embeddings can still appear in answers. Freshness is part of correctness.
Embedding model upgrades are migrations. Versioned embeddings, dual indexes, shadow queries, backfills, and rollback decide whether search quality survives.
The best vector database depends on ownership boundaries, filter semantics, recall targets, migration paths, cost, and operational maturity - not benchmark screenshots.
Chunk size and overlap decide retrieval quality, citation accuracy, freshness, permissions, and cost. Treat chunks as serving data with ownership.
Vector search observability needs recall, result count, filter selectivity, freshness lag, tenant skew, index health, reranker cost, and answer grounding - not just latency.
Multi-tenant vector search is a correctness and isolation problem. Namespaces, filters, and partitions each fail differently under tenant skew and ACL rules.
Vector search looks easy until tenant filters, permissions, freshness, and deleted content arrive. The hard part is not nearest neighbors; it is filtered recall under production rules.
Hybrid search helps when exact terms and semantic meaning both matter. It fails when teams blend rankings without query intent, calibration, or evaluation.
Vector cost is not just storage. Dimensions, top_k, filters, rerankers, embedding refreshes, payload size, index rebuilds, and tenant skew all compound.
The hard vector database decision is not pgvector versus Pinecone on a checklist. It is whether your filters, recall target, update rate, and incident budget still fit inside Postgres.