Vector Database Selection
Comparing Pinecone, Weaviate, pgvector, Qdrant, and Chroma for production RAG. Features, pricing, scaling characteristics, and when to use each.
Quick Reference
- →pgvector: simplest ops — runs in your existing Postgres, perfect for <1M vectors
- →Pinecone: fully managed serverless, scales to billions, zero ops burden
- →Qdrant: high-performance filtering + vector search, open-source with managed option
- →Weaviate: hybrid search built-in, GraphQL API, good for complex query patterns
- →Chroma: local development and prototyping, lightweight, embeds in your app
- →For most teams: start with pgvector, migrate to a dedicated vector DB when you hit scale limits
pgvector — Vector Search in Postgres
pgvector adds vector similarity search to PostgreSQL. If your application already uses Postgres, pgvector is the lowest-friction path to production RAG. No new infrastructure, no new ops skills, no new billing. You get ACID transactions, familiar SQL, and your vectors live alongside your relational data. The tradeoff is performance at scale — pgvector is slower than purpose-built vector databases beyond ~1M vectors without careful index tuning.
pgvector supports HNSW and IVFFlat indexes. For <100K vectors, a sequential scan is fast enough. For 100K-1M vectors, create an HNSW index: CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64). This brings query time from seconds to milliseconds.
| Vectors | Without Index | With HNSW Index | Recall@10 |
|---|---|---|---|
| 10K | 5ms | 2ms | 100% |
| 100K | 50ms | 5ms | 99.5% |
| 1M | 500ms | 10ms | 98% |
| 10M | 5s+ | 20ms | 95% |