A vector database is a data store purpose-built for indexing, storing, and querying high-dimensional floating-point vectors — the kind produced when an embedding model encodes a document, image, or audio clip. Rather than matching rows by exact column values the way a relational database does, a vector database retrieves the nearest neighbours of a query vector using approximate nearest-neighbour (ANN) algorithms such as HNSW or IVF. This makes similarity search over millions of embeddings practical in tens of milliseconds.

Think of it like a library where books are not sorted alphabetically or by genre, but placed on shelves according to meaning. Books about similar topics end up physically close together, so when you bring in a new text and ask "what is this most like?", the librarian simply walks to the nearest shelf rather than scanning every title in the catalogue.

Vector databases power retrieval-augmented generation pipelines. At query time a user's question is embedded and sent to the vector database to fetch the most relevant document chunks, which are then inserted into the model's prompt:

import chromadb
client = chromadb.Client()
collection = client.get_collection("docs")
results = collection.query(
    query_embeddings=[query_vec],
    n_results=5,
)
context_chunks = results["documents"][0]

Popular options include Pinecone, Weaviate, Qdrant, and Chroma, each with different trade-offs between hosting model, indexing speed, and filtering support.

Vector databases are tightly coupled with Embedding models that produce the vectors, RAG architectures that retrieve context for generation, and LLMs that consume the retrieved chunks. The Latent Space concept explains why geometric proximity in vector space corresponds to semantic similarity.

You will encounter vector databases whenever you build semantic search, recommendation systems, or any LLM application that needs to ground responses in a private document corpus.