Vector databases became one of the most over-hyped infrastructure choices of 2024. The hype settled by 2026 into a clearer picture: most apps do not need a dedicated vector database. Postgres with pgvector handles millions of embeddings reliably. But when you do need scale, filtering, or multi-tenancy, dedicated options like Qdrant and Pinecone are production-ready and genuinely better. Here is how to make the choice correctly.
What changed in 2026
- pgvector 0.7+ ships HNSW indexing by default. Approximate nearest-neighbor search at scale is now a first-class Postgres feature, not a workaround.
- Qdrant became the leading open-source option. Its Rust implementation handles 100M+ vectors efficiently and has a clean API. Qdrant managed (cloud) reduced the ops burden.
- Pinecone added serverless. Pinecone Serverless eliminated idle costs — pay per query, not per provisioned pod. Changes the economics for bursty workloads.
- Hybrid search became standard. Every serious vector DB now ships hybrid dense+sparse (BM25) search. Apps that only use vector search get worse RAG results.
- Weaviate and Chroma stabilized. Both are production-usable. Chroma remains more popular for prototyping; Weaviate for complex filtering use cases.
The options compared
| Database |
Type |
Best for |
Managed? |
Scale |
| pgvector |
Postgres extension |
Most apps |
Via Railway/Supabase |
Up to ~50M vectors |
| Qdrant |
Dedicated (Rust) |
Open-source, large scale |
Yes (cloud) |
100M+ vectors |
| Pinecone |
Dedicated (proprietary) |
Fully managed, serverless |
Yes |
Billion+ vectors |
| Weaviate |
Dedicated (Go) |
Complex filtering, GraphQL |
Yes |
100M+ vectors |
| Chroma |
Dedicated (Python) |
Prototyping, local dev |
No |
Small–medium |
| Redis with Search |
Add-on |
Existing Redis users |
Yes |
Medium |
When pgvector is enough
pgvector is the right choice when:
- You already run Postgres
- Your embedding count is under ~10–50M
- You need simple top-k nearest neighbor search
- You want one fewer infrastructure component
-- pgvector: create table with embedding column
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT,
embedding vector(1536) -- for OpenAI text-embedding-3-small
);
-- HNSW index for fast approximate search
CREATE INDEX ON documents
USING hnsw (embedding vector_cosine_ops);
-- Query: find 5 most similar documents
SELECT id, content,
1 - (embedding <=> $1) AS similarity
FROM documents
ORDER BY embedding <=> $1
LIMIT 5;
When to use a dedicated vector database
Move to a dedicated vector DB when you have:
- 100M+ vectors — pgvector query latency degrades and memory pressure increases
- Complex metadata filtering — filter by tenant, date, category, etc. at query time without loading everything
- Multi-tenancy at scale — namespace isolation per customer is cleaner in dedicated DBs
- Hybrid search — BM25 + vector in a single query; pgvector requires extra joins with pg_trgm
Hybrid search: the real differentiator
RAG applications that use only vector search miss keyword-matched results. Hybrid search is better:
# Qdrant hybrid search example
from qdrant_client import QdrantClient
from qdrant_client.models import SparseVector, NamedSparseVector
results = client.query_points(
collection_name="docs",
prefetch=[
# Dense vector search
{"query": dense_embedding, "using": "dense", "limit": 20},
# Sparse (BM25) keyword search
{"query": SparseVector(indices=sparse_indices, values=sparse_values),
"using": "sparse", "limit": 20},
],
# Fuse results with RRF
query={"fusion": "rrf"},
limit=5,
)
How to pick
- Under 10M vectors, running Postgres? pgvector. No new service.
- 10–100M vectors, open-source preference? Qdrant self-hosted or managed.
- 100M+ vectors, need fully managed? Pinecone Serverless.
- Complex filtering at scale? Weaviate or Qdrant — both handle payload filtering well.
- Just prototyping locally? Chroma — zero setup, Python-native.
Common mistakes
Premature migration to a dedicated vector DB. The most common mistake. pgvector handles the scale most apps ever reach. Do not add infra before you need it.
Not indexing. pgvector without an HNSW or IVFFlat index will do brute-force search. For more than a few thousand vectors, create the index.
Ignoring embedding model consistency. All vectors in a collection must come from the same embedding model. Mixing models produces nonsensical similarity scores.
Chunking too large or too small. Embeddings of 500–1000 token chunks perform better than whole-document embeddings or sentence-level embeddings for most RAG use cases.
What to skip
- Self-hosting Pinecone — it is proprietary; you are using the managed service or nothing.
- Chroma in production — it is excellent for development but not designed for production scale and durability.
- Embedding entire documents — chunk them first; retrieval precision is far better on bounded chunks.
FAQ
Can I use SQLite for vector search?
sqlite-vec exists and works for very small datasets (thousands of vectors). For anything production-scale, Postgres + pgvector is the next step up.
How many dimensions should my embeddings have?
OpenAI text-embedding-3-small uses 1536 dimensions. Smaller models use 384–768. Fewer dimensions = faster search, lower storage. Match the model you are using.
Is Chroma production-ready?
Not for most definitions of production. Use it for local development and prototyping; migrate to pgvector or Qdrant before going live.
How do I measure vector search quality?
Use recall@k: for a test query, what fraction of the true top-k results appear in your top-k retrieved results. Good hybrid search should hit recall@5 > 0.85 for most RAG use cases.
Where to go next
How to build a RAG app in 2026 shows how to wire a vector database into a full retrieval-augmented generation pipeline. Best backend for AI apps in 2026 covers the full server-side stack including where vector storage fits. Build an app with AI in 2026 shows the end-to-end workflow for AI-assisted app development.