Vector database

A database designed to store embeddings and quickly find the ones most similar to a search query, enabling search by meaning.

When you convert documents into embeddings (lists of numbers representing meaning), you need somewhere to store and search them efficiently. A vector database does exactly this: you store millions of embeddings, and when a user asks a question, the database finds the stored items whose numerical representations are closest to the query's. "Closest" here usually means "most similar in meaning." This is the storage layer that makes semantic search and RAG possible at scale.

Builder example

If you are building a RAG system over thousands of company documents, the vector database is where all your document chunks live as embeddings. Search quality depends on two things working together: a good embedding model that captures meaning accurately, and a vector database that retrieves the closest matches quickly. Store metadata (document date, source, category) alongside every embedding. Without it, you lose the ability to filter results, and the system might surface a five-year-old policy when the user needs the current one.

You ask about current pricing. The vector database returns last year's pricing document because the language is almost identical.

Add metadata filters like date or version, combine vector search with keyword search, and test retrieval with real questions before trusting it.

Common confusion: "Closest" means most mathematically similar embedding, which is not always the most useful or correct answer. Two document chunks can be semantically close while saying contradictory things.