Brave Search API

More Search API pages

API glossary

Vector database

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A vector database is a database built to store and search embeddings—the high-dimensional numeric vectors that represent the meaning of text, images, or other data. Instead of matching records by exact values like a traditional database, a vector database finds the records whose vectors are most similar to a query, which is what makes meaning-based (semantic) search possible at scale.

In short: a vector database stores embeddings and finds the most similar ones to a query—the storage-and-search engine behind semantic search and RAG.

How a vector database works

The job is to store vectors and find the nearest ones to a query, fast:

  1. Store vectors: Each item is converted into an embedding and stored, usually with metadata such as source, title, and tags attached.
  2. Index for speed: Vectors are organized with an approximate nearest neighbor index such as HNSW (hierarchical navigable small world), a graph-based structure that navigates toward near matches quickly rather than scanning every stored vector.
  3. Search by similarity: A query is embedded into a vector, and the database returns the nearest vectors using a similarity metric like cosine similarity, each with a retrieval score.
  4. Filter and return: Results can be narrowed by metadata (such as date or category) and then returned already ranked by similarity.

Because comparing a query to every vector by brute force is too slow at scale, vector databases use approximate nearest neighbor (ANN) search, trading a little accuracy for a large gain in speed, so similarity search stays fast even across millions or billions of vectors.

Vector database vs. relational databases and search libraries

  • Relational databases retrieve rows by exact matches and filters; a vector database retrieves by similarity in meaning. The question shifts from “equals” to “most like.”
  • Vector search libraries such as FAISS (an open-source library from Meta) primarily provide ANN indexing and similarity-search primitives; a vector database wraps persistence, metadata filtering, updates, serving, and scaling around those capabilities.
  • Vector databases store similarity-based representations; a knowledge graph stores explicit, labeled facts and relationships. One is statistical, the other symbolic, and the two are often combined.

Where vector databases are used

  • Semantic search: Storing a corpus as embeddings so queries match by meaning, powering semantic search over a body of documents.
  • RAG: Holding the chunked, embedded knowledge a RAG system retrieves from at query time.
  • Recommendations and similarity: Finding similar products, images, or songs by vector proximity.
  • Common architecture pattern: Teams often pair a vector database with a search API: the vector database handles the corpus they ingest (often proprietary, but potentially licensed or public data), while the search API supplies fresh, open-web results.

A vector database matters when you need to search by meaning over an embedded corpus at scale, and it is often one half of a retrieval stack (with a search API handling complementary web retrieval).

Embeddings, semantic search, retrieval-augmented generation (RAG), chunking, retrieval score, cosine similarity, approximate nearest neighbor (ANN), knowledge graph, search API.