Definition
A vector database is a data service designed to store vectors and retrieve similar vectors efficiently, usually with metadata and filtering around the search path.
In an AI retrieval system, the stored vector often represents a real object:
document chunk -> embedding vector -> vector store entry
The database needs to answer:
given this query vector,
which stored entries should become candidates?
Why This Concept Exists
Vector search starts as a comparison problem. Production turns it into a data-system problem.
The system must manage:
- many vectors
- IDs and payload metadata
- index builds
- inserts, updates, and deletes
- query-time filters
- tenant and permission boundaries
- backups, scaling, and observability
A vector database packages those concerns around similarity retrieval instead of leaving every product team to build them from scratch.
Data Model Shape
A stored vector record often carries more than the vector itself:
id
vector
metadata
payload reference
Metadata may include:
- document ID
- chunk ID
- tenant
- language
- timestamp
- visibility state
- product category
That metadata matters because nearest-neighbor similarity alone is rarely the full query.
Query Shape
A query may combine:
query vector
top-k count
metadata filters
similarity metric
index path
The result may return IDs, scores, metadata, and sometimes payload fields. A downstream service may then fetch full text, rerank candidates, or assemble context for a model.
query embedding -> vector database -> candidate IDs -> payload fetch -> rerank or prompt
What The Database Does Not Solve Alone
A vector database does not decide:
- whether your embedding model is right
- how documents should be chunked
- whether retrieved chunks answer the user's question
- how to ground a generated answer
- how permission policy should be designed
It supports the retrieval layer. It does not replace retrieval design.
Operational Tradeoffs
Vector databases introduce familiar data-system questions with AI-specific pressure.
Index build and update path: new embeddings need to become searchable without making rebuilds unmanageable.
Memory and storage: high-dimensional vectors and indexes can be expensive.
Filtering: metadata filters should preserve correctness without destroying query performance.
Freshness: document edits, deletes, and re-embedding jobs need visible lifecycle rules.
Recovery: rebuilding an index from durable source data should be possible.
Vendor and architecture fit: some products need a dedicated vector service; others can begin with vector support inside an existing search or database stack.
Failure Modes
Common operational failures include:
- vectors and payloads get out of sync
- deletes remain searchable longer than product policy allows
- metadata filters leak or hide results
- index rebuilds create long freshness gaps
- re-embedding migrations mix incompatible vector versions
- vector search latency looks fast while payload hydration or reranking dominates the user path
The database is one component in the larger retrieval pipeline.
Product Examples
A document assistant can store chunk embeddings and metadata for tenant-safe retrieval.
A product catalog can store product vectors with category, region, and availability filters.
A support system can keep ticket or article embeddings searchable for related-case discovery.
A multimodal search product can store embeddings for image or text assets as long as the retrieval space and metadata model are coherent.