# Choosing a Vector Database

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

Category: Guide · Updated: 2026-06-25 · Tags: vector-databases, rag, retrieval, pgvector, infrastructure, agents
Canonical: https://changegamer.ai/resources/choosing-a-vector-database
Variants: [HTML](https://changegamer.ai/resources/choosing-a-vector-database) · [JSON](https://changegamer.ai/api/resources/choosing-a-vector-database.json)
License: https://changegamer.ai/license.xml · Access: free

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

| Option | Type | Best when | Main tradeoff |
|---|---|---|---|
| **pgvector** | Add-on (Postgres) | Already on Postgres; < ~100 M vectors; need ACID | Ops tied to Postgres; limited distributed scale |
| **Qdrant** | Dedicated (self-host/managed) | Production RAG; strong filtered + hybrid search | More infra than pgvector if you have no dedicated stack |
| **Weaviate** | Dedicated (self-host/managed) | Object store + vector; multi-tenant SaaS | Heavier footprint; config complexity |
| **Milvus** | Dedicated (self-host) | Billion-scale; distributed | Complex deployment |
| **Pinecone** | Fully managed | No-ops priority; serverless auto-scale | Vendor lock-in; per-query cost at high QPS |
| **Elasticsearch / OpenSearch** | Add-on (search cluster) | Already running ES/OS; want BM25 hybrid | Not purpose-built; operational weight |
| **MongoDB Atlas Vector Search** | Add-on (Atlas) | Already on Atlas; vector + document in one query | Atlas-only; managed cost |
| **Redis** | Add-on (cache layer) | Ultra-low latency; data already in Redis | Memory-bound; less suited to large cold corpora |
| **LanceDB** | Embedded / managed | Columnar analytics + vectors; multimodal | Single-node OSS; Enterprise for distributed |
| **Chroma** | Embedded / managed | Local dev, prototyping, teaching | Single-node; limited production hybrid story |
| **FAISS** | Library (no server) | Research; custom pipelines; recall baseline | No server/persistence — you build everything |

## 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

---

## Related resources

- [RAG and Retrieval for Agents](https://changegamer.ai/resources/rag-retrieval-for-agents.md): End-to-end practitioner reference for Retrieval-Augmented Generation: pipeline stages, chunking strategies, dense/sparse/hybrid retrieval, reranking, agentic retrieval patterns, quality failure modes, and evaluation — with verified sources for every named technique.
- [Agent Memory and Context Management](https://changegamer.ai/resources/agent-memory-context.md): Architecture reference for agent memory: types (working, long-term, episodic, semantic, procedural), context-management techniques (summarization, RAG, sliding windows, prompt caching), storage substrates, and memory frameworks — with security notes and cross-links to related guides.
- [Chunking Strategies for RAG](https://changegamer.ai/resources/chunking-strategies-for-rag.md): Practitioner reference for chunking documents before embedding: fixed-size, recursive, semantic, late chunking, and contextual retrieval — with a strategy comparison table, chunk-size and overlap tradeoffs, code/table/Markdown handling, embedding model context limits, and evaluation methods.
- [Hybrid Search for RAG: BM25 + Dense Retrieval and Fusion](https://changegamer.ai/resources/hybrid-search-for-rag.md): How to combine lexical (BM25/SPLADE) and dense vector retrieval with Reciprocal Rank Fusion for higher first-stage recall in RAG pipelines — with the RRF formula, a sparse-method comparison table, and verified DB support.

---

Index of all resources: https://changegamer.ai/llms.txt · Full corpus: https://changegamer.ai/llms-full.txt · Corpus data (NDJSON): https://changegamer.ai/api/corpus.jsonl · Offers: https://changegamer.ai/api/pricing.json