pgvector vs
Dedicated Vector DB.

Side by side

The argument most comparisons miss

Benchmarks compare raw nearest-neighbour throughput, and that is rarely the constraint in a real application. The queries production systems actually run look like: find the passages most similar to this question, restricted to documents this user is permitted to see, excluding archived items, within this date range.

That is a similarity search combined with several structured filters, and it is where naive setups fall apart. In Postgres it is one query with proper indexes and correct results. With a separate vector store you must either duplicate permission and status metadata into it and keep that copy synchronised, or over-fetch candidates and filter afterwards — which silently degrades recall when the filter is selective, because the true nearest permitted neighbour may not be in the top k you retrieved.

When a dedicated system earns its place

Genuine scale is the clearest trigger. Beyond several million vectors, keeping the index resident in Postgres memory competes with your transactional workload, and purpose-built systems offer disk-based and quantised indexes designed for that regime.

High sustained query rates matter too: if vector search is your primary traffic rather than an occasional lookup, isolating it protects your operational database. Managed options also make sense when you want someone else to own index tuning and scaling — that is a legitimate reason to pay, not a technical concession.

And some workloads need index features Postgres does not offer, such as aggressive product quantisation for very large collections or specialised multi-vector retrieval.

What to get right either way

The choice of store is less consequential than three things that determine retrieval quality regardless. Chunking — what you embed matters more than where you keep it. Hybrid search — pure vector similarity fails on part numbers, proper nouns, and exact identifiers, so combine it with keyword matching. Reranking — retrieve a wider candidate set cheaply, then reorder with a cross-encoder; this is frequently the largest single quality gain available. See RAG for how these fit together.

Plan for re-embedding from the start whichever you pick. Vectors from different embedding models are incomparable, so a model upgrade means regenerating the entire index. Keep the source content and the embedding pipeline reproducible so that is a scheduled job rather than an incident.