Vector database patterns determine whether your AI feature returns relevant results in 50ms or a confused mess in 800ms. The vector database market matured rapidly in 2024-2025 — pgvector, Pinecone, Weaviate, Qdrant, and Milvus all hit production-grade reliability with different trade-offs. Picking the right one and using it well comes down to a handful of patterns. The teams shipping good AI search are doing the same five things. Here is what to copy.
Table of Contents
Index Choice Matters More Than Provider
HNSW (Hierarchical Navigable Small World) is the default for most production vector indexes — fast queries, reasonable build time, good recall. IVF (Inverted File) trades query speed for lower memory. Flat (no index) is only for small collections under 100K vectors.
For pgvector, choose HNSW unless you have specific memory constraints. The defaults (m=16, ef_construction=64) are good starting points. The pgvector HNSW documentation covers the parameter trade-offs.
Metadata Filtering Changes Everything
The killer feature of modern vector DBs is filtered search — find similar vectors that also match metadata constraints (user_id = X, category = Y, created_at > Z). Done naively, this is slow. Done with a proper hybrid index, it is fast.
pgvector with proper b-tree indexes on filter columns + HNSW on vectors handles this well. Pinecone and Weaviate both have native metadata filtering with optimized execution. For multi-tenant apps, this is non-negotiable. Combine with our production RAG patterns for end-to-end retrieval design.
Embedding Choice Drives Recall
The embedding model you choose dictates what “similar” means. OpenAI text-embedding-3-large, Voyage voyage-3, BAAI bge-large-en-v1.5, and Cohere embed-v3 all perform differently on different domains. Test on your actual data before committing.
Most teams default to OpenAI without testing alternatives that might be faster, cheaper, or more accurate for their use case. Build an eval set of 50-100 representative queries with known relevant results and benchmark embeddings on that. The MTEB leaderboard is a starting point but your domain matters more than general benchmarks.
Dimensions Matter for Cost and Speed
Embedding dimensions impact storage cost, query speed, and recall. text-embedding-3-large at 3072 dimensions is more accurate than text-embedding-3-small at 1536, but uses 2x storage and ~2x query time.
Matryoshka embeddings let you truncate dimensions while preserving most of the recall — text-embedding-3-large truncated to 1024 is often nearly as good as the full version at 1/3 the storage cost. Worth testing for high-volume use cases.
Batch Inserts and Async Indexing
Inserting vectors one at a time is dramatically slower than batched inserts. Most vector databases support batch operations of 100-1000 vectors per request. Use them — the difference is 10-100x throughput.
For large initial loads, async indexing strategies (insert with index disabled, build index after bulk load) finish dramatically faster than incremental indexing. The Qdrant optimization documentation covers patterns that apply across vector databases.
Wrap Up
Vector database patterns done right give you fast, accurate semantic search that scales to millions of vectors. Pick the right index (HNSW for most), use filtered search aggressively, benchmark embeddings on your data, optimize dimensions, and batch your inserts. Most teams overthink vector DB choice and underthink embedding choice — the latter usually has a bigger impact on quality. Combine with Redis patterns for caching frequently-accessed embeddings.
Frequently Asked Questions
pgvector or dedicated vector DB?
pgvector for under 10M vectors and existing Postgres infrastructure. Dedicated vector DB (Pinecone, Qdrant, Weaviate) for higher scale, multi-tenancy isolation, or specific feature needs (hybrid search, vector clustering).
How many vectors can one database handle?
pgvector handles 10M+ comfortably with HNSW. Pinecone and Qdrant scale to billions. Performance depends on dimensions, recall requirements, and hardware as much as raw count.
Should I store the source text in the vector DB?
Store enough metadata to display results (title, snippet, ID) but keep full source text in your primary database. Vector DBs are optimized for vector operations, not text storage.
How do I update embeddings when my model changes?
Backfill in the background — generate new embeddings, write to a new collection or index, atomically swap. Plan for 10-50% extra storage during the migration window.
What about hybrid search (vector + keyword)?
Use it. Pure vector search misses exact term matches; pure keyword search misses semantic ones. Reciprocal rank fusion of the two consistently outperforms either alone for real-world queries.
