Vector databases store embeddings and run similarity search for retrieval-augmented generation, and the main options differ less in core search than in…
Establish the common core before comparing the options.
Every vector database does the same fundamental thing: store embeddings with metadata, build an approximate nearest neighbor (ANN) index like HNSW, and return the closest vectors to a query, usually with metadata filtering. For a typical RAG app, the core search quality is broadly similar across the good options.
So the choice is rarely about who can find nearest neighbors — they all can. It is about how you operate the thing: how it scales, how much you manage, its cost model, and how well it fits the rest of your stack.
Identify the dimensions that separate the options.
The meaningful differences are operational. Managed vs self-hosted: a managed service removes ops work but costs more and keeps your data with a vendor; self-hosting is cheaper at scale and keeps control but you run it. Scale: some options target billions of vectors and high throughput, others are happiest at smaller sizes.
Cost model: per-usage managed pricing versus your own compute. Ecosystem fit: whether you want vectors alongside existing relational data, and how the database integrates with your tools. These, not raw recall, drive the decision.
Compare the common vector databases on the dimensions that matter.
Option | Model | Sweet spot ----------|--------------------|--------------------------- Pinecone | fully managed | scale without running infra Weaviate | OSS + cloud | features + hybrid, flexible Qdrant | OSS + cloud | performance, self-host Milvus | OSS + cloud | very large scale Chroma | lightweight/local | prototyping, small apps pgvector | Postgres extension | vectors beside relational
Read by fit, not a winner: Pinecone trades cost for zero ops; Weaviate, Qdrant, and Milvus are open-source engines (self-host or managed) spanning features to massive scale; Chroma is easiest to start locally; pgvector keeps vectors in the Postgres you already operate. Core search is comparable — the row that fits your ops and stack is the pick.
Apply a decision rule and avoid the common traps.
A practical rule: if you already run Postgres and have up to millions of vectors, start with pgvector. If you want to prototype fast and locally, use Chroma. If you want scale without operating infrastructure, choose a managed service like Pinecone. If you want open-source control at large scale, pick Qdrant, Weaviate, or Milvus, self-hosted or as their cloud.
Start with the least operational option that meets your scale, and migrate only if you outgrow it. Most projects over-choose early.
Watch for: picking on benchmark recall when core search is similar and ops matter more; over-provisioning a heavyweight distributed system for a few hundred thousand vectors; ignoring metadata-filtering and hybrid-search needs when comparing; and forgetting the vector store complements, not replaces, your primary database. Also plan for embedding-model changes, which require re-indexing regardless of the database.
Vector databases all store embeddings, build an ANN index, and do filtered similarity search, so core quality is comparable. The real differences are operational: managed (Pinecone) vs self-hosted open-source (Qdrant, Weaviate, Milvus), lightweight local (Chroma), or vectors-in-Postgres (pgvector). Choose by scale, ops appetite, and stack fit: pgvector if you run Postgres, Chroma to prototype, managed for scale without ops, open-source engines for control at scale. Start minimal and migrate only if you outgrow it.
You're choosing a vector store for a RAG app expecting ~2 million vectors, already on Postgres, with a small team. Recommend an option and justify it against a managed alternative, and name one future change (like swapping the embedding model) you'd plan for regardless of choice.
What do the main vector databases mostly share?
All good options do the core job well; the decision hinges on operations, scale, cost, and stack fit rather than raw recall.
What actually differentiates vector databases?
Since core search is comparable, the meaningful differences are how you run and scale the database and its ecosystem fit.
When is pgvector a good first choice?
pgvector keeps vectors in an existing Postgres with SQL filtering, fitting most RAG apps up to millions of vectors.
What is a common mistake when choosing a vector database?
Recall differences are small among good options; over-choosing early adds ops burden, so match the tool to real scale and needs.