Vector database
A database optimized for storing and querying high-dimensional embedding vectors — enabling semantic search, RAG, and similarity-based retrieval at scale.
Vector databases are the storage layer for RAG and any agent that needs semantic retrieval. You encode each document chunk as an embedding vector; the database indexes vectors for approximate-nearest-neighbor search; queries are encoded the same way and matched against the index.
The 2026 landscape: Pinecone and Weaviate lead the dedicated-vector-DB market. Postgres with pgvector covers most teams that already run Postgres. Specialized indexes like Qdrant, Milvus, and Chroma fill niches. The performance gap between purpose-built and pgvector has narrowed dramatically for sub-50M vector workloads.
For agent stacks, the choice usually defaults to "what does my data platform already support." Postgres + pgvector for teams already on Postgres. Pinecone for managed simplicity. Qdrant or Weaviate for self-hosted scale. The vector DB rarely becomes the bottleneck — usually the embedding strategy or retrieval pipeline does.
Where this shows up
Frequently asked
Do I need a dedicated vector database?+
Not always. For under 10M vectors and existing Postgres infrastructure, pgvector covers most use cases. Move to Pinecone, Qdrant, or Weaviate when you need sub-50ms p99 at 100M+ vectors or specialized index types.
Pinecone vs Weaviate vs Qdrant vs pgvector — what should I pick?+
Pinecone for managed simplicity. Weaviate for self-hosted with built-in hybrid search. Qdrant for performance-focused self-hosted. pgvector when you already run Postgres and need under 10M vectors.
How big are embedding vectors in 2026?+
Common dimensions: 768 (smaller models), 1536 (OpenAI ada-002), 3072 (OpenAI text-embedding-3-large). Larger dimensions improve accuracy but cost more in storage and compute. Binary and quantized embeddings cut storage 4–32× with small accuracy loss.