Vector database

What is a vector database?

A vector database is a specialised data store that holds and searches vectors. A vector is a list of numbers that captures the meaning of a piece of text, image, or audio. Those numbers are produced by an embedding model and behave like a fingerprint: similar items sit close together, different items sit far apart.

Where a classic SQL database searches for exact values or ranges, a vector database searches by meaning. Look up "dog" and you also get results about "puppy", "labrador", or "four-legged friend", even when those words never appear in the text. That is semantic search in a nutshell.

You can picture a vector database as a library where books are organised by theme and mood rather than by title or author. Two different books on parenting sit right next to each other, even if they share no words in the title.

Why do vector databases exist?

Classic databases are built for exact matches or ranges: WHERE age > 30, WHERE name = 'John'. For meaning-driven queries they fall short. Keyword search misses synonyms, paraphrases, and context.

The rise of embeddings changed that. Text, images, and audio can be translated into vectors of hundreds or thousands of dimensions. Finding the nearest neighbours in that space at scale needs specialised indexing, and that is exactly what a vector database does.

The real breakthrough came with RAG. Language models need a memory that reaches further than their training data and their limited context window. A vector database provides that memory.

How does a vector database work?

Indexing
When you add a document, the text is first split into smaller chunks. Each chunk runs through an embedding model and becomes a vector. The vector is stored in the index together with metadata such as source, date, author, or access rights.

Searching
When a user asks a question, the question is also turned into a vector. The database looks for the k closest vectors, usually with an approximate nearest neighbour algorithm like HNSW, IVF, or ScaNN. This is deliberately not exact, because perfect search across millions of vectors becomes too slow.

Filtering
Alongside semantic similarity you can filter on metadata, for example only this year, only this customer, or only public documents. Good vector databases combine vector search and metadata filtering in a single query.

Hybrid search
Pure vector search sometimes misses exact tokens like part numbers or acronyms. Hybrid search combines vector results with a classic keyword index such as BM25, which typically produces more reliable answers.

When do you use a vector database?

1. RAG chatbots on your own documents. The classic use case. Employees or customers ask questions, the chatbot pulls relevant passages from your documentation and generates an answer with citations.

2. Semantic search engines. Searching on intent rather than wording. Useful for knowledge bases, legal files, and product catalogues where each item carries little text.

3. Recommendation systems. Find items that look like what a user recently viewed. Works for products, articles, music, and video.

4. Fraud and anomaly detection. Compare new transactions against a vector profile of normal behaviour and flag outliers for investigation.

5. Deduplication. Match articles, customer records, or images that are nearly identical without being exactly equal, a common need in master data management.

Popular vector databases

Azure AI Search
Microsoft's search service now offers full vector search and hybrid search. Tight integration with Azure OpenAI and Microsoft Fabric makes it the natural pick in a Microsoft stack.

Pinecone
Fully managed, often showing up in rapid RAG prototypes. Easy to adopt, but proprietary and not cheap at scale.

Qdrant and Weaviate
Open source alternatives you can self-host or buy as a managed service. A common pick for teams that want to avoid vendor lock-in.

pgvector
A PostgreSQL extension. Handy when you already run Postgres and want to keep operational complexity low. Fine for indexes up to a few million vectors.

Milvus
Open source, strong on very large volumes and multi-modal data. Popular in research environments.

Pitfalls

Embedding quality sets the ceiling
Search quality is never better than the embedding model. An outdated or wrong-language model misses half the queries. Test with a representative set of questions in the language your users actually speak before going live.

Access rights and permissions
Vector search results must never show more than the requester is allowed to see. Filters on permission metadata at query time are not optional, especially in combination with row level security on the source.

Vector versioning
Swap out the embedding model and you have to re-embed every existing vector. Plan for that in any major upgrade, because switching halfway through produces mixed-quality results.