Vector database

A vector database stores embeddings (typically arrays of 768 to 3,072 floating-point numbers per item; OpenAI's text-embedding-3-small produces 1,536 and text-embedding-3-large 3,072) and answers one core question very quickly: "given this query vector, which N vectors in the index are closest?" That is k-nearest-neighbor (k-NN) search over high-dimensional space, and doing it in milliseconds across millions or billions of vectors is the entire reason these databases exist. Under the hood, exact k-NN is too slow for production scale, so vector DBs use approximate nearest neighbor (ANN) algorithms such as HNSW, IVF, and ScaNN that trade a tiny amount of recall for huge speedups. They also handle the things real systems need: metadata filtering (only search vectors tagged with user_id=42), hybrid search (combine vector similarity with keyword scores), namespaces, and incremental indexing. The 2026 landscape: Pinecone for managed simplicity, Qdrant and Weaviate for self-hosted production workloads, Chroma for prototyping and small projects, pgvector for teams that already run Postgres and do not want another system, and Milvus for very large self-hosted indexes. Cloud providers have native offerings too: Amazon S3 Vectors (generally available since December 2025) and OpenSearch k-NN on AWS, Azure AI Search, and Vector Search on Google's Gemini Enterprise Agent Platform (formerly Vertex AI). As a rule of thumb, below about a million vectors many teams skip a dedicated vector database entirely, because pgvector or an in-memory FAISS index is fast enough. A vector database handles retrieval and nothing else. Search quality is bounded by your embedding model and your chunking; the database makes the lookup fast.