Vector Databases

Concepts Covered

• Vector databases
• Vector storage
• Collections and payloads
• Metadata filters
• Vector indexes
• Query serving
• Freshness
• Rebuild and re-embedding work
• Operational tradeoffs

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.

Related Topics

• Vector Search
• Vector Embeddings
• RAG In Plain English