What is a vector database? A search system built for finding nearby embeddings

In Lesson 021, an embedding turned text or images into vectors so that similar meanings could be placed near one another.

That leads to a practical problem: what if you have ten million vectors?

Comparing a query against every stored vector one by one can become expensive. A vector database is designed to store vectors and retrieve nearby ones efficiently.

It is still a database, but similarity is a first-class operation

Traditional databases are excellent at questions such as:

• user_id = 123,
• price < 100,
• created_at after yesterday.

Vector systems add another important question:

Which stored vectors are most similar to this query vector?

That is commonly called nearest-neighbor search.

Why use an index?

If you search every vector exactly, the work grows with the size of the collection.

Vector databases therefore use specialized index structures and approximate-nearest-neighbor methods to find strong candidates much faster.

“Approximate” does not mean random. It means the system trades a small possibility of missing the mathematically exact nearest item for much better speed and scale.

The exact index may use graph-based, inverted or quantized structures depending on the product.

Metadata still matters

Similarity alone is rarely enough.

Suppose a support system stores embeddings for every document in a company. A user should not retrieve documents they are not allowed to see.

A vector search may therefore combine semantic similarity with metadata filters such as:

• tenant or user ID,
• language,
• document type,
• time range,
• access-control label,
• product category.

This is why a production vector database is more than a bag of floating-point arrays.

What gets stored?

A typical record may include:

• the vector,
• the original text or a pointer to it,
• document ID,
• chunk number,
• metadata,
• timestamps or permissions.

When a query arrives, the app creates a query embedding, retrieves nearby records and then decides how to use them.

Vector databases do not replace every database

If you need exact transactions, relational constraints or account balances, a normal relational database is usually still essential.

Vector search solves a different problem: similarity retrieval.

Many real applications use both SQL and vector search.

The connection to RAG

A common AI pattern is:

1. split documents into chunks,
2. create embeddings,
3. store them in a vector database,
4. embed the user’s question,
5. retrieve relevant chunks,
6. send those chunks to a language model.

That pattern is part of Retrieval-Augmented Generation (RAG), the topic of Lesson 023.

One thing to remember

A vector database stores embeddings and is optimized to retrieve items whose vectors are close to a query, often together with normal metadata filters.