A vector database is a database designed to store vector embeddings and quickly find the vectors most similar to a query vector. Traditional databases match exact values; a vector database ranks by similarity. It is the storage layer behind most RAG systems, semantic search and recommendation engines.
Key takeaways
- Stores vectors plus the original text and metadata.
- Uses approximate nearest neighbour indexes to search millions of vectors in milliseconds.
- Metadata filtering, for permissions or dates, is as important as the similarity search itself.
- Options range from dedicated services to extensions for existing databases.
- The database performs the search; vector search is the operation it runs.
A vector database explained in simple terms
A normal database is a filing cabinet with labelled folders: you find things by knowing the label. A vector database is a map where similar documents sit close together. You drop a pin where your question is and pick up whatever is nearby, even if nothing shares a keyword.
What a record contains
| Field | Purpose |
|---|---|
| id | Unique identifier for the chunk |
| vector | The embedding, typically a few hundred to a few thousand numbers |
| text | The original passage, returned with results |
| metadata | Source URL, title, date, document type, access tags, version |
Metadata is what makes a vector store usable in production. Without it you cannot filter by permission, restrict to recent documents or show a citation.
Key capabilities to look for
- Filtered search: combine similarity with metadata conditions efficiently.
- Hybrid search: keyword and vector scoring together.
- Upserts and deletes: documents change; the index must change with them.
- Namespaces or collections: separate tenants or knowledge bases.
- Scalability: millions to billions of vectors, with predictable latency.
- Backups and security: encryption, access control, audit logs.
The main options
| Type | Examples | Suits |
|---|---|---|
| Dedicated managed services | Pinecone and similar hosted offerings | Teams wanting minimal operations |
| Open-source vector databases | Weaviate, Qdrant, Milvus, Chroma | Self-hosting and control |
| Extensions to existing databases | pgvector for PostgreSQL | Teams already running Postgres who want one system |
| Search engines with vector support | Elasticsearch, OpenSearch | Existing search infrastructure and strong hybrid support |
| Libraries | FAISS | Embedded use and experimentation |
For small projects, an existing database with a vector extension is often the pragmatic choice. Dedicated systems earn their place at larger scale or when advanced filtering and hybrid ranking matter.
A worked example
A company indexes 200,000 document chunks with a 1,024-dimension embedding model.
- Raw vector storage: 200,000 × 1,024 × 4 bytes ≈ 820 MB, before index overhead.
- Each record also stores its text and metadata.
- A query embeds the question, filters to documents the user may access, and returns the top 50 candidates in a few milliseconds for a reranker to refine.
Limitations
- Similarity is not relevance; retrieved chunks may be related but unhelpful.
- Changing embedding models means re-embedding everything.
- Approximate search trades a little accuracy for speed.
- Another system to operate, secure and back up.