# Vector Database

> A vector database stores embeddings and answers nearest-neighbor queries fast — the retrieval layer under RAG and semantic search, using ANN indexes like HNSW.

**A vector database stores [embeddings](/glossary/embedding) and answers the query "which stored vectors are closest to this one?" fast enough for production — the retrieval layer beneath [RAG](/glossary/rag) and [semantic search](/glossary/semantic-search).**

The hard problem it solves is scale. Exact nearest-neighbor search means comparing the query against every vector — fine at ten thousand, hopeless at a hundred million. Vector databases use **approximate nearest neighbor (ANN)** indexes, dominated by HNSW graphs, to get sub-millisecond lookups at a small, tunable recall cost. Around that core they layer the production necessities: metadata filtering ("only docs from this tenant"), hybrid keyword+vector search, quantization to shrink memory, and replication.

The market splits three ways: **Postgres-native** ([pgvector](/tools/pgvector)) riding your existing database, **open-source engines** ([Qdrant](/tools/qdrant), Weaviate, Milvus, Chroma, LanceDB), and **managed services** (Pinecone). The honest decision guide — including when plain pgvector is the right answer — is [Best Vector Database in 2026](/guides/database/best-vector-database-2026); tuning the index you pick is the [embedding-index-tuner](/skills/database/embedding-index-tuner) skill's job.

---

_Source: https://agentscamp.com/glossary/vector-database — Term on AgentsCamp._
