---
title: "What Is a Vector Database?"
description: "A vector database stores embeddings and finds the ones closest in meaning to a query, which is how RAG and semantic search retrieve relevant text fast."
type: "glossary"
locale: "fr"
term: "Vector Database"
canonical: "https://agenticschool.dev/fr/glossary/vector-database"
dateModified: "2026-07-07"
---

# What Is a Vector Database?

- Definition: Vector Database
- Updated: 2026-07-07
- Keywords: vector database, what is a vector database, vector db, vector store, vector database for rag
- Canonical URL: https://agenticschool.dev/fr/glossary/vector-database
- Locale: fr

> A vector database stores embeddings and finds the ones closest in meaning to a query, which is how RAG and semantic search retrieve relevant text fast.

A vector database is a database built to store embeddings - the numeric vectors that represent the meaning of text, images or code - and to find, in milliseconds, the ones most similar to a query vector. A normal database is great at exact matches ("find the row where id = 42"), but it cannot answer "find the passages that mean roughly the same thing as this question". A vector database can, because it indexes by distance in meaning-space rather than by exact values. That single capability - fast nearest-neighbour search over embeddings - is what powers retrieval-augmented generation (RAG), semantic search and recommendations at scale.

## What it actually does

You embed your content into vectors and store them. At query time you embed the incoming question and ask the database for the k nearest vectors. It returns them almost instantly, even across millions of items, using an approximate nearest-neighbour index. The returned items are the passages, products or records closest in meaning to what was asked.

- Store: keep each embedding alongside its original text and metadata.
- Index: build an approximate nearest-neighbour index so search stays fast at scale.
- Query: embed the question, retrieve the k closest vectors, return their source content.

## Vector database vs a normal database

A relational or document database matches on exact fields and keywords. A vector database matches on semantic similarity, so a query worded completely differently from the stored text still finds it. They are complements, not rivals: many systems filter by metadata in a normal query and rank by vector similarity, and several traditional databases now add vector indexes so you get both in one place.

## When you need one

You need a vector database as soon as RAG or semantic search grows past a toy size. For a few hundred items you can compare vectors in memory; past that, a dedicated vector index keeps retrieval fast and cheap. It is the storage layer that lets an agent reason over your private documents, a support bot answer from your help center, and a search box return results by meaning rather than exact words.

## FAQ

### What is a vector database in simple terms?

A vector database stores embeddings - lists of numbers that capture meaning - and quickly finds the ones closest to a query. It answers "what is most similar in meaning to this?" instead of "what exactly matches this value?", which is what semantic search and RAG need.

### How is a vector database different from a normal database?

A normal database matches exact values and keywords; a vector database matches by semantic similarity between embeddings. One finds "id = 42", the other finds "passages that mean roughly this". Many real systems combine both: metadata filters plus vector ranking.

### Do I always need a vector database for RAG?

Not for a tiny corpus - you can compare a few hundred vectors in memory. Once you have thousands or millions of chunks, a vector database keeps nearest-neighbour search fast and affordable, which is why it is standard in production RAG systems.

### What do vector databases store besides the vector?

Alongside each embedding they keep the original text or a reference to it, plus metadata like source, author, permissions or timestamp. That metadata lets you filter results and enforce access rules, so retrieval stays both relevant and secure.