Vector Store

A vector store (or vector database) is a storage system purpose-built to hold high-dimensional numeric vectors — embeddings — and retrieve the ones most similar to a query vector, typically using approximate nearest neighbor (ANN) search. Unlike a traditional relational database, which excels at exact-match lookups ("find the row where id = 42"), a vector store answers a fundamentally different question: "find the 10 rows whose meaning is closest to this one." This makes it the backbone of retrieval-augmented generation (RAG), semantic search, recommendation engines, and de-duplication systems. Why it matters for AI/SaaS builders: any product that lets an LLM "know" your documents, support tickets, product catalog, or codebase needs a vector store sitting between the raw data and the model. Without one, you're stuck stuffing everything into the context window (expensive, slow, and capped by context limits) or doing brittle keyword search that misses paraphrases ("cancel my plan" vs. "how do I stop being billed"). How it works: text (or images, audio) is passed through an embedding model, which outputs a fixed-length vector (e.g., 1536 floats for OpenAI's text-embedding-3-small). The vector store indexes these vectors using a structure like HNSW (Hierarchical Navigable Small World graphs) so that similarity search runs in milliseconds even across millions of vectors, instead of the seconds a brute-force comparison would take. Most vector stores also let you attach metadata (source URL, date, user ID, tags) to each vector and filter on it during search (metadata filtering), and many now support hybrid search — blending vector similarity with traditional keyword (BM25) scoring for better precision on exact terms like product SKUs or error codes. Popular options split into dedicated vector databases (Pinecone, Weaviate, Qdrant, Milvus) and vector extensions bolted onto general-purpose databases (pgvector for PostgreSQL, Redis with the RediSearch module, MongoDB Atlas Vector Search). The choice usually comes down to scale, operational simplicity, and whether you already run Postgres or Redis in production. Worked example: a SaaS support-desk product ingests 50,000 historical help articles. Each article is chunked into ~500-token passages, embedded, and upserted into a vector store with metadata `{article_id, product_area, last_updated}`. When a user asks "why is my invoice showing double charges?", the app embeds that question, queries the vector store for the top 5 nearest passages filtered to `product_area = "billing"`, and passes those passages plus the question to an LLM to generate a grounded answer — the RAG pattern in miniature.