Learn
What is a vector database?
A vector database stores embeddings and retrieves nearest neighbors by semantic similarity — the retrieval layer behind RAG, agent memory, and recommendation. It answers 'what chunks are most like this query?' at scale.
In depth
Traditional databases match exact keys; vector databases match meaning. You embed documents into vectors, index them (HNSW, IVF, etc.), and query with an embedded question to get top-k similar chunks.
In agent stacks, vector DBs sit between raw corpora and the LLM: ingest → chunk → embed → store → retrieve on each task. Metadata filters (date, department, customer id) narrow results before similarity search.
Options in 2026: Pinecone, Weaviate, Qdrant, pgvector on Postgres, managed offerings from cloud vendors. Choice depends on scale, ops appetite, and residency requirements.
Neuro OS connectors broker access — agents retrieve through scoped roles, not by holding raw DB credentials in prompts.
Examples
- Support KB — embed tickets; retrieve similar resolved cases
- pgvector — vectors inside existing Postgres
- Hybrid search — vectors + BM25 keyword for better recall
- Metadata filter — 'docs tagged finance AND 2025'
- Agent RAG — top 8 chunks injected into context window
Related terms
FAQ
Do I always need a vector DB?
For small corpora, brute-force search or keyword search may suffice. Vector DBs pay off at thousands+ chunks and frequent retrieval.
Vector DB vs embedding model?
The model produces vectors; the database stores and searches them. Both are required for semantic retrieval at scale.
Run governed agent roles on a company OS — not only definitions in a glossary.