Vector database

A database optimized for storing high-dimensional vectors (embeddings) and finding the nearest neighbors of a query vector efficiently.

A vector database stores embedding vectors and supports approximate nearest-neighbor (ANN) queries — "give me the 10 vectors closest to this one". Real-world ANN engines (HNSW, IVF, ScaNN) trade a tiny bit of recall for huge speed gains, so you can query a million vectors in milliseconds. They matter because vanilla relational databases were never built for this. Searching a million 1536-dimensional vectors with brute-force cosine similarity is slow; a vector database makes it cheap. Every RAG system needs one — without efficient retrieval, you can't ground LLM answers in your data. A typical setup: you embed every paragraph in your documentation, store (paragraph_text, embedding, metadata) rows in a vector DB, and at query time you embed the user question, query the DB for top-k similar vectors, and feed those paragraphs to the LLM as context. The whole pipeline runs in 100-300ms. Popular options: Pinecone (managed), Weaviate, Qdrant, Milvus, Chroma (open-source); pgvector turns Postgres into a competent vector store and is now the default for Supabase + Neon. For small projects, pgvector or Chroma are usually enough; large-scale workloads (>50M vectors, multi-region) push toward Pinecone or Milvus. Related: embedding, RAG, HNSW, hybrid search.