Vector databases have moved from a niche research tool to a core component of AI applications over the past few years. They enable a type of search that keyword-based databases cannot perform well: finding items that are semantically similar to a query, even if they share no exact words in common.
What is a vector?
In the context of databases, a vector is a list of numbers — a mathematical representation of meaning. When text (or an image, or audio) is processed by an embedding model, it is converted into a high-dimensional vector — often with 768, 1536, or more dimensions — that encodes its semantic content.
The key property is that similar content produces vectors that are close together in this high-dimensional space. The sentence "The cat sat on the mat" and "A feline rested on a rug" will have vectors that are close to each other, even though they share few words.
How similarity search works
Given a query, a vector database finds the vectors in its collection that are closest to the query vector. "Closeness" is typically measured with cosine similarity (the angle between vectors) or Euclidean distance.
Searching across millions of vectors by brute force — computing the distance to every vector in the database — would be too slow. Vector databases use approximate nearest neighbor (ANN) algorithms such as HNSW (Hierarchical Navigable Small World) or IVF (Inverted File Index) to make this search fast, trading a small amount of accuracy for large speed gains.
The embedding model matters
The quality of a vector search system depends heavily on the quality of the embedding model. The embedding model converts raw data into vectors, and if it does a poor job of encoding semantic meaning, similarity search will not work well.
For text, common embedding models include:
- OpenAI's text-embedding-3-small and text-embedding-3-large
- Sentence Transformers (open source, from HuggingFace)
- Cohere Embed
- E5 and BGE models
The choice of model affects the vector dimensions, the quality of semantic similarity, and whether the model handles domain-specific vocabulary well.
What vector databases add beyond basic ANN search
A vector database is more than an ANN index. It also provides:
Metadata filtering: Store structured metadata alongside vectors and filter by it at query time. "Find documents similar to this query, where document_type = 'technical' AND date > '2024-01-01'."
CRUD operations: Add, update, and delete individual vectors without rebuilding the entire index.
Persistence and replication: Data survives restarts and can be replicated for reliability.
Multi-tenancy: Logical separation of collections for different applications or users.
Popular vector databases
Several databases are optimized for vector workloads:
Pinecone: Managed cloud service, simple API, good scalability. No self-hosting option.
Weaviate: Open source, rich querying, can combine vector and keyword search natively.
Chroma: Lightweight, easy to run locally, well-suited for development and smaller datasets.
Qdrant: Open source, performant, good filtering, can be self-hosted or used as a managed service.
pgvector: PostgreSQL extension that adds vector storage and search. Useful if you are already using Postgres and do not need extreme scale.
Redis: With the RedisVector module, can be used for vector search in applications already using Redis.
Vector search vs. keyword search
Traditional keyword search (used by systems like Elasticsearch or Postgres full-text search) works by matching exact or stem-matched words. It is fast and interpretable but fails when the query and relevant documents use different vocabulary.
Vector search finds semantically relevant results regardless of vocabulary. It handles synonyms, paraphrasing, and conceptual similarity naturally. But it is harder to debug (why did it return this result?), requires good embedding models, and adds infrastructure complexity.
Hybrid search — combining vector and keyword scores — often outperforms either approach alone, and most modern search systems move in this direction.
When to use a vector database
Use a vector database when:
- You need semantic search (find items by meaning, not just keywords)
- You are building a RAG system and need to retrieve relevant document chunks
- You are building recommendation systems (find items similar to what a user liked)
- You are doing image, audio, or multi-modal search
A traditional database is sufficient when:
- You only need exact or pattern-based matching
- Your dataset is small (a few thousand items at most)
- You do not have AI-generated embeddings in your pipeline
Summary
Vector databases store data as numerical embeddings and enable fast approximate nearest-neighbor search. They are the backbone of RAG systems and semantic search applications. The quality of the embedding model significantly affects search quality. Most vector databases add metadata filtering, persistence, and CRUD operations on top of the core similarity search capability. Choosing between a dedicated vector database and a general-purpose database with vector extensions depends on scale, existing infrastructure, and operational complexity constraints.