Top picks by use case
| Use case | Recommended | Why |
|---|---|---|
| Smallest setup / prototyping | Chroma or in-memory FAISS | Embedded; zero ops; great DX |
| Already on Postgres | pgvector | Skip the new dependency; query alongside relational data |
| Self-hosted, production-ready | Qdrant or Weaviate | Both mature, open-source, with good clustering and ops story |
| Managed / serverless | Pinecone or Weaviate Cloud | Pay-as-you-go; no infrastructure to operate |
| Massive scale (billions of vectors) | Milvus | Built for very large fleets; horizontal scale |
| Strong hybrid search (vector + keyword) | Weaviate, Qdrant, Elasticsearch | BM25 + vector fusion as a first-class feature |
The six contenders
Embedded vector store with the lowest setup friction. Great for getting from "I want to try RAG" to running code in minutes. Single-machine performance is excellent for prototype and small production workloads.
Best for: notebooks, prototypes, single-machine deployments under a few million vectors.
A Postgres extension that adds vector columns and ANN indexes. The killer feature: query your existing relational data and vector data in one SQL statement. For teams already running Postgres, pgvector typically wins on operational simplicity even when other databases are technically faster.
Best for: teams with existing Postgres expertise, applications mixing structured and unstructured queries.
Open-source Rust-based vector DB with a clean ops story. Strong performance, good hybrid search support, payload filtering that integrates well with vector queries. Production-grade clustering and replication. Cloud-hosted option available.
Best for: production self-hosted workloads, teams that want strong filtering alongside vector search.
Fully-managed vector database; no infrastructure to operate. Strong API ergonomics, transparent pricing, serverless tier that scales with usage. The convenience tax is real but justified for teams without infra capacity. Less attractive if you have your own platform team.
Best for: startups and teams that want to outsource ops, applications with variable load.
Open-source vector + keyword hybrid search engine with a robust schema model. Good multi-tenancy support, strong ANN performance, integrates well with frontier embedding models out of the box. Available self-hosted or managed.
Best for: applications that need both vector and keyword (BM25) search, multi-tenant SaaS, RAG with rich metadata filtering.
Designed for vector workloads at billions-of-vectors scale. Cloud-native architecture (separated compute and storage), good support for distributed deployments. More operational complexity than smaller options but the only choice for truly massive corpus sizes.
Best for: very large vector workloads (100M+ vectors), enterprise deployments with dedicated ops.
How to actually pick
The decision is dominated by three questions, in this order:
- Self-hosted or managed? Managed (Pinecone, Weaviate Cloud) removes ops at higher per-vector cost. Self-hosted (Qdrant, Weaviate, Milvus) means you operate it.
- How much data? Under 10M vectors: any option works. 10M-100M: most options work; ops matters. 100M+: Milvus and the managed options at scale. Billions: Milvus or specialized infrastructure.
- What integrates best with your stack? Already on Postgres? Use pgvector. Already on Elasticsearch? Use its dense_vector field. Greenfield with no constraints? Start with Chroma for prototyping, Qdrant or Pinecone for production.
What matters less than people think
- Raw ANN benchmark scores. Above a threshold, latency differences don't affect UX. RAG latency is dominated by the LLM call, not the vector search.
- Specific ANN algorithm (HNSW, IVF, ScaNN). All major DBs support tunable indexes; the algorithm name matters less than how the DB lets you tune it.
- Specific dimension limits. Above 256 dimensions, all major options handle storage and search adequately.
What matters more than people think
- Metadata filtering quality. Real RAG queries filter by user, tenant, source — vector + filter performance matters more than raw vector speed.
- Ingest throughput. Bulk-loading millions of vectors during an initial reindex. Some options are 10x faster than others here.
- Recall at low cost. Achieving 95% recall is cheap; 99% is expensive. Test what your accuracy floor really is.
- Operational complexity. Managed services trade higher unit cost for someone else doing the on-call. Worth it for small teams.
Frequently Asked Questions
What is a vector database?
A database optimized for storing and searching high-dimensional embedding vectors. Given a query vector, it returns the K most similar vectors from a corpus using approximate nearest neighbor (ANN) algorithms. Used as the retrieval backend in RAG (retrieval-augmented generation) and semantic search applications.
Do I need a vector database for RAG?
Not always. For small corpora (under ~100k documents), in-memory FAISS or even pgvector can be sufficient. Dedicated vector databases shine when you need millions of vectors, multi-tenant isolation, or production-grade ops features (replication, snapshots, hybrid search).
Is pgvector good enough for production?
Yes for many workloads. pgvector handles tens of millions of vectors comfortably with good index settings. Beyond that, dedicated vector DBs scale better. The argument for pgvector is simplicity — one database to operate instead of two.
What is hybrid search?
Combining vector similarity with keyword (BM25) search. Reciprocal rank fusion merges the two result sets to produce better recall than either alone. Critical for queries that mix semantic meaning with specific identifiers, code symbols, or exact names. Weaviate, Qdrant, and Elasticsearch handle this natively.
How much does a vector database cost?
Self-hosted: hardware + ops time. A few-million-vector workload runs on a single mid-sized server for low hundreds of dollars per month. Managed: Pinecone starts around $70/month for a small index; scales to thousands at production volume. Cost grows with total vectors stored, query rate, and dimensions.