Embeddings & Vector Databases
Last updated: 2026-05-18
What Are Embeddings and Vector Databases?
Embeddings are numerical representations of text (or images) that capture meaning. Similar content produces similar vectors — numbers that are close together in a high-dimensional space. That property enables semantic search: find things by meaning, not just by matching words. Vector databases store these vectors and retrieve the nearest matches quickly. They're the storage layer for RAG, recommendations, and similarity search.
Think of embeddings as coordinates for meaning. "Dog" and "puppy" are close together; "dog" and "tax return" are far apart. The database finds what's near your query.
Embeddings: Turning Meaning Into Numbers
An embedding model converts text into a vector — a list of hundreds or thousands of numbers. The model is trained so that:
- Semantically similar text has similar vectors
- The distance between vectors reflects semantic distance
You don't need to understand the math. The key point: meaning maps to position. "Find documents about project timelines" will match docs discussing "deadlines," "schedules," and "milestones" even if those exact words don't appear, because their embeddings are close.
Why This Matters
Traditional search matches keywords. If you search "car repair," you get documents containing those exact words. You miss "automotive maintenance" or "vehicle servicing" unless the system has synonyms explicitly built in. Semantic search retrieves what's conceptually relevant, even with different wording.
That enables:
- RAG — Retrieve relevant document chunks for a question, then generate an answer
- Recommendations — "Find items similar to this one"
- Deduplication — Detect near-duplicate content
- Clustering — Group similar items
Vector Databases
A vector database is built for one job: store vectors and return the k nearest neighbors to a query vector, fast. Relational databases can do this with extensions (e.g., pgvector), but purpose-built systems (Pinecone, Weaviate, Qdrant, Chroma) are optimized for scale and speed.
How it works — You ingest documents, embed them, and insert vectors into the database. At query time, you embed the query and ask for the top k similar vectors. The database returns the closest matches.
Key features — Filtering (by date, category, etc.), hybrid search (combining vector and keyword), and metadata storage. Different databases trade off latency, scale, and feature set.
The RAG Connection
RAG depends on embeddings and vector databases. Documents are chunked, embedded, and stored. A user question is embedded and used to retrieve relevant chunks. Those chunks are passed to the model as context. Without embeddings, you'd need keyword search — less accurate for natural language questions. Without a vector database, similarity search at scale would be too slow.
When You Need a Vector Database
You need one when:
- You're running RAG over more than a few hundred documents
- You need semantic search or recommendations
- You have thousands or millions of vectors
- Latency matters (sub-100ms retrieval)
You might not need one when:
- Keyword search is sufficient
- Your corpus is tiny (in-memory search can work)
- You use a managed RAG product that includes storage
The Model Directory includes embedding providers and vector databases. Filter by "embeddings," "vector database," or "RAG" to find options.