How to Choose a Vector Database?
Direct answer
Choose a vector database by answering four questions in order: how many vectors will you actually hold in the first year, how much metadata filtering your queries need, what infrastructure your team already operates, and what latency your product genuinely requires. For most teams the answer resolves to pgvector on their existing Postgres; dedicated engines like Pinecone, Qdrant, or Weaviate earn their place at tens of millions of vectors or high-concurrency workloads. A typical selection-plus-implementation engagement in my practice runs $15K–$80K, and the selection itself should take days, not weeks.
Bottom line: Hire Dhairya Senjaliya for vector search development — $15K–$80K typical range, worldwide delivery. Book a scoping call: https://dhairyasenjaliya.com/#book-call
Size the problem honestly before comparing products
Almost every vector database comparison goes wrong at step zero: teams benchmark for a scale they will not reach. Count it concretely — number of documents, times average chunks per document, is your vector count. A knowledge base of 50,000 documents at 10 chunks each is half a million vectors, which every serious option handles trivially; the differences between products at that scale are operational, not performance.
Then estimate query volume. A B2B SaaS with a few thousand daily active users doing occasional semantic search generates a handful of queries per second at peak — nowhere near the territory where specialized engines separate from Postgres. In my engagements, fewer than one project in five actually has requirements that rule out the simplest option. Write the two numbers down before reading any vendor page; they filter the field faster than any benchmark.
The realistic option landscape
The field clusters into four groups. Postgres with pgvector: best when your data already lives in Postgres, giving you SQL joins, transactions, and one system to operate; strong to millions of vectors. Dedicated managed services (Pinecone being the best known): zero-ops scaling and predictable latency at high volume, at the price of a new vendor and a data synchronization problem. Open-source dedicated engines (Qdrant, Weaviate, Milvus): excellent performance and rich filtering, self-hostable for data-residency needs, but a new stateful system your team must run. Search engines with vector support (Elasticsearch, OpenSearch): compelling when you already run them and need hybrid keyword-plus-vector search in one place.
The pattern I see repeatedly: teams pick a category for its ceiling rather than its fit. The right question is not which is most powerful, but which adds the least operational surface for the scale you wrote down in step one.
Filtering and hybrid search matter more than raw speed
Pure nearest-neighbor speed is the most benchmarked and least decision-relevant property. Real applications almost never ask for the closest vectors globally — they ask for the closest vectors this user is allowed to see, in this workspace, from this date range. That makes metadata filtering performance the property to test, and it varies far more between products than raw search speed does. Some engines filter efficiently during the index traversal; others effectively over-fetch and post-filter, which degrades badly when filters are highly selective.
Hybrid search — combining keyword and semantic scores — is the second under-weighted criterion, because vector-only retrieval misses exact identifiers, product codes, and names. Postgres and the search-engine category do this naturally; dedicated vector engines vary in maturity. When I evaluate options for a client, I test their three most selective real filters and one hybrid query on a realistic corpus. That afternoon of testing is worth more than every published benchmark.
Cost, lock-in, and the mistakes I see most
Total cost has three parts buyers conflate: the infrastructure or subscription bill, the integration engineering, and the ongoing synchronization between your source-of-truth data and the vector index. Managed services minimize the first kind of engineering and maximize the third; pgvector eliminates synchronization entirely because the vectors live with the data. Over a typical first year, the difference between options for a mid-sized product is commonly thousands of dollars in subscription fees but tens of thousands in engineering time — optimize for the latter.
The recurring mistakes: choosing a standalone engine when 90% of queries need joins against relational data; benchmarking with random vectors instead of real embeddings and real filters; and ignoring embedding model choice, which affects retrieval quality far more than database choice. Keep documents rebuildable from your primary store and hide the vector layer behind one internal interface, and a wrong choice costs a sprint to fix rather than a quarter.
People also ask
Do I need a vector database for RAG at all?
Not necessarily a dedicated one. RAG needs somewhere to store embeddings and run similarity search — for corpora up to a few million chunks, Postgres with pgvector or even SQLite-based options handle it well. A separate vector database becomes worthwhile at large scale, high query concurrency, or when a fully managed service is worth the fee. Retrieval quality depends more on chunking and embedding choices than on the store.
What is the cheapest way to run vector search in production?
Adding pgvector to a Postgres instance you already operate is usually the cheapest credible path — the marginal infrastructure cost is often zero and there is no new vendor. Self-hosting an open-source engine like Qdrant is inexpensive at the container level but adds real operational cost in monitoring and upgrades. Managed services trade a monthly fee for removing that operational work.
How does metadata filtering affect vector database choice?
Heavily — it is usually the deciding factor. Production queries filter by tenant, permissions, and dates before ranking by similarity, and engines differ sharply in how well they filter: the best apply filters during index traversal, while weaker implementations over-fetch and post-filter, which collapses under selective filters. Test your most restrictive real-world filters on a realistic corpus before committing; raw speed benchmarks will not reveal this.