← All resources

Choosing a Vector Database

Guide · updated 2026-06-25 · Markdown variant

Criteria-based decision guide: dedicated vs. add-on vector stores, scale thresholds, hybrid search support, self-host vs. managed, and a start-here recommendation.

Choosing where to store and search vectors is an infrastructure decision, not an embedding or algorithm decision. This guide covers selection criteria only — for index types (HNSW/IVF) and embedding models see /resources/embeddings-vector-search; for the full RAG pipeline see /resources/rag-retrieval-for-agents; for hybrid retrieval see /resources/hybrid-search-for-rag.

Key facts

• Where vectors get stored and searched is fundamentally an ops/infrastructure call, separate from which embedding model or ANN algorithm you pick.
• Vector stores fall into four types: extensions to a database you already run, dedicated vector databases, embedded in-process libraries, and fully managed cloud services.
• Scale drives the choice: small corpora tolerate almost any option, tens of millions of vectors push you toward purpose-built or columnar stores, and billion-scale deployments need systems engineered specifically for that volume.
• Combining vector similarity with keyword matching is table stakes for real-world RAG deployments, and which products support it natively differs a lot as of 2026.
• Handling storage yourself keeps costs and data under your control but adds real operational work; letting a vendor manage it removes that maintenance burden at a higher price point.
• For teams already on Postgres, layering in pgvector is the lowest-friction starting point; those without a database already chosen tend to land on Qdrant, the most frequently suggested open-source dedicated engine.

What type of vector store do you need?

• Extension / add-on — vector search added to a database you already operate: pgvector (PostgreSQL), Redis vector search, Elasticsearch/OpenSearch kNN, MongoDB Atlas Vector Search.
• Dedicated vector database — purpose-built, vector search is the primary API: Pinecone, Qdrant, Weaviate, Milvus.
• Embedded library — runs in-process, no server: LanceDB OSS, Chroma (in-process), FAISS.
• Managed cloud service — fully hosted, no infra to operate: Pinecone Serverless, Qdrant Cloud, Weaviate Cloud, MongoDB Atlas.

Decision axes

Vector count (scale) — below ~1 M vectors almost anything works; at 10 M+ dedicated DBs (Qdrant, Milvus) and columnar stores (LanceDB) are designed for it; at billion+ scale Milvus Distributed and Pinecone Serverless are purpose-engineered. pgvector reaches hundreds of millions with HNSW but needs careful tuning.

Filtered metadata search — all named dedicated DBs support pre-filtering; pgvector supports WHERE clauses that interact with the vector index. Filtered-search accuracy varies — Qdrant and Pinecone document accuracy-preserving filtered search explicitly.

Hybrid search (vector + keyword) — required for most production RAG. Verified native support (mid-2026): Qdrant (dense+sparse, RRF), Weaviate (BM25F + vector fusion), Milvus (BM25 + dense + sparse), Elasticsearch/OpenSearch (BM25 + kNN), MongoDB Atlas ($rankFusion/$scoreFusion), Redis (FT.HYBRID in recent versions), LanceDB. pgvector is not native but Postgres gives you tsvector full-text + vectors, fused with RRF at the query layer. Chroma is better for dev than production hybrid.

Self-host vs. managed — operational cost often exceeds storage cost. Managed services remove ops burden at a price premium; self-hosted options trade ops work for cost control and data sovereignty.

Consistency — pgvector inherits Postgres ACID guarantees (ideal when vectors must stay transactionally consistent with relational data); dedicated DBs vary from eventual to strong — verify for your write pattern.

Cost model — embedded libs: compute only; pgvector: free extension + your Postgres host; dedicated self-hosted: free software + your servers; managed: per read/write/storage or per cluster. Compare total cost at your query volume, not just storage.

Option comparison

Start here

• Already run PostgreSQL? Add pgvector first — HNSW/IVFFlat indexes, transactional consistency, no new infrastructure; pair with tsvector + RRF for hybrid. Migrate to a dedicated store only when you hit operational pain or scale limits.
• No existing database constraint? Qdrant is the most commonly recommended open-source dedicated vector DB for production RAG as of 2026 — native hybrid, strong filtered ANN, Apache 2.0, self-hosted or managed.
• Development/prototyping only? LanceDB OSS or Chroma (in-process) — iterate with no infra.
• Billion-scale? Pinecone Serverless (no-ops) or Milvus Distributed (self-hosted).
• Existing Elastic/OpenSearch stack? Use its built-in kNN + BM25 hybrid — no new DB needed.

Verified sources

• pgvector (PostgreSQL extension): https://github.com/pgvector/pgvector
• Qdrant hybrid search: https://qdrant.tech/articles/hybrid-search/
• Weaviate hybrid search: https://weaviate.io/blog/hybrid-search-explained
• Milvus overview: https://milvus.io/docs/overview.md
• Pinecone: https://www.pinecone.io/
• MongoDB Atlas hybrid search ($rankFusion / $scoreFusion): https://www.mongodb.com/blog/post/product-release-announcements/boost-search-relevance-mongodb-atlas-native-hybrid-search
• Redis hybrid search (FT.HYBRID): https://redis.io/blog/revamping-context-oriented-retrieval-with-hybrid-search-in-redis-84/
• Elasticsearch hybrid search: https://www.elastic.co/search-labs/blog/hybrid-search-elasticsearch
• LanceDB: https://github.com/lancedb/lancedb
• Chroma: https://github.com/chroma-core/chroma
• FAISS (Meta AI): https://github.com/facebookresearch/faiss

#vector-databases #rag #retrieval #pgvector #infrastructure #agents

Category: Guide