Vector Database
The database that stores meaning as numbers — the Sorting Hat's filing system, indexed for semantic retrieval.
A vector database stores data as dense numerical vectors — the embedding representations of text, images, or other content produced by embedding models. Unlike traditional relational databases (optimized for exact matches and structured queries) or full-text search engines (optimized for keyword matching), vector databases are optimized for approximate nearest neighbor (ANN) search: finding the stored vectors most similar to a query vector, measured by cosine similarity or dot product. This enables semantic similarity search — finding documents that are conceptually related to a query even when they share no common words. If you embed a customer support knowledge base and a user asks "Why is my invoice wrong?", semantic search will surface articles about "billing disputes," "payment adjustments," and "invoice corrections" even if the articles never use the phrase "invoice wrong."
Leading vector database products include Pinecone, Weaviate, Qdrant, Chroma (open-source, popular for prototyping), and pgvector (a PostgreSQL extension that adds vector capabilities to an existing relational database). Each offers different tradeoffs around scale, query complexity, latency, and operational complexity. Pinecone is fully managed and scales to billions of vectors without infrastructure management; pgvector is the right choice when you already run Postgres and don't want additional infrastructure for moderate vector volumes; Qdrant and Weaviate offer open-source options with rich filtering capabilities that allow combining vector search with structured metadata filters ("find semantically similar documents from this category, from this date range, with this status").
For B2B teams building RAG applications, selecting and sizing a vector database is a practical infrastructure decision. The key parameters are: corpus size (how many vectors will be stored), query latency requirements (milliseconds matter for real-time applications, less so for batch processing), filtering complexity (does semantic search need to be combined with structured attribute filters?), and operational overhead tolerance. For initial prototypes and small corpora, pgvector or Chroma provide a fast start with no new infrastructure. For production applications with large corpora and high query volumes, a dedicated vector database with managed scaling typically delivers better performance and reliability than embedding vector search into a general-purpose database.
Related terms
- Embedding— Numeric representation of meaning — Elvish rune encoding, but as floating-point vectors optimized for semantic search.
- Retrieval-Augmented Generation (RAG)— Giving your LLM access to the Restricted Section — so it answers from real knowledge instead of confident hallucination.
- Semantic Search— Finding results by meaning rather than keyword match — 'Accio relevant context' without knowing the exact incantation.
- Grounding— Anchoring AI responses in verifiable data — insisting the model look at the actual Palantír rather than guess what it shows.
- Knowledge Graph— A structured map of concepts and their relationships — the Elvish taxonomy of everything your AI needs to understand.