5 min read
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.
6 min read
HNSW defaults can look fast while missing useful results. Production tuning needs recall@k, p99, index build time, memory, and filtered result count together.
6 min read
A fast RAG system can still be wrong. Production teams need recall@k, MRR, answerability, citation coverage, freshness, no-hit rate, and drift signals.
5 min read
A RAG system is unsafe if deleted documents, permission changes, and stale embeddings can still appear in answers. Freshness is part of correctness.
6 min read
Embedding model upgrades are migrations. Versioned embeddings, dual indexes, shadow queries, backfills, and rollback decide whether search quality survives.
7 min read
The best vector database depends on ownership boundaries, filter semantics, recall targets, migration paths, cost, and operational maturity - not benchmark screenshots.
6 min read
Chunk size and overlap decide retrieval quality, citation accuracy, freshness, permissions, and cost. Treat chunks as serving data with ownership.
5 min read
Vector search observability needs recall, result count, filter selectivity, freshness lag, tenant skew, index health, reranker cost, and answer grounding - not just latency.
6 min read
Multi-tenant vector search is a correctness and isolation problem. Namespaces, filters, and partitions each fail differently under tenant skew and ACL rules.
6 min read
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.
6 min read
Hybrid search helps when exact terms and semantic meaning both matter. It fails when teams blend rankings without query intent, calibration, or evaluation.
5 min read
Vector cost is not just storage. Dimensions, top_k, filters, rerankers, embedding refreshes, payload size, index rebuilds, and tenant skew all compound.
15 min read
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.