A vector database is a specialised database optimised for storing and searching high-dimensional vectors — typically embeddings of text, images or other content — by similarity. Where a traditional database finds rows by exact match on a column, a vector database finds rows whose vectors are closest to a query vector under cosine similarity, dot product or Euclidean distance. It is the storage layer beneath retrieval-augmented generation, semantic search, recommendations and most other AI features that lean on embeddings.
The 2026 vector database landscape:
- pgvector — Postgres extension; the default for teams already running Postgres. Production-ready up to tens of millions of vectors with proper indexes.
- Pinecone — managed cloud vector DB, scales to billions of vectors with ease.
- Qdrant — open-source, self-hostable, strong on metadata filtering.
- Weaviate — open-source, hybrid search and rich schema support.
- Chroma — embedded vector DB; popular for local development and small-to-medium projects.
- Milvus — open-source, designed for very large scale.
- Turbopuffer — newer, serverless, optimised for cost at scale.
- Cloud-native options — AWS OpenSearch with vector support, Azure AI Search, Google Vertex AI Matching Engine.
The core operations:
- Upsert — add a vector with associated metadata.
- Query — find the top-k vectors most similar to a query vector.
- Filter — query with metadata constraints ("similar to X but only from documents tagged Y").
- Hybrid search — combine vector similarity with keyword (BM25) ranking; almost always more accurate than pure vector search.
- Delete and reindex — manage the lifecycle as documents change.
The architectural decisions for a US team in 2026:
- Already on Postgres? Start with pgvector. No new infrastructure, transactional guarantees, joins with the rest of your data. Production-proven up to tens of millions of vectors.
- Need to scale beyond pgvector? Pinecone (managed) or Qdrant (self-hosted) are the safe defaults.
- Strict cost control at very high scale? Turbopuffer or self-hosted Milvus.
- Need rich filtering and schema? Weaviate or Qdrant lead here.
- Multi-modal (text + image embeddings together)? Most modern vector DBs handle this; the question is your embedding model strategy.
The operational concerns:
- Index parameters matter — HNSW vs IVF, m and ef parameters; the defaults are usually fine but tuning can improve recall and latency significantly.
- Embedding model versioning — when you upgrade your embedding model, every existing vector needs re-embedding. Plan for it.
- Per-tenant isolation — multi-tenant SaaS needs strict isolation; namespaces in Pinecone, separate collections in Qdrant.
- Cost growth — vector storage is more expensive than blob storage; tens of millions of vectors at production query volume can run into thousands per month.
For a US team building anything that uses embeddings (RAG, semantic search, recommendation, deduplication, classification), a vector database is core infrastructure. The category has matured to the point where almost any choice works for typical workloads — the operational care goes into your embedding strategy, your retrieval pipeline and your evaluation harness rather than into the vector DB itself.
