Vector Database

In one line

A database whose primary index is built for fast approximate nearest-neighbour search over high-dimensional embeddings.

What it actually means

You insert records as (id, vector, metadata) triples. The database builds an ANN index — HNSW, IVF-PQ, DiskANN — that lets it return the top-k closest vectors to a query in milliseconds even at hundreds of millions of rows. Most of them also support metadata filters (only chunks from this tenant, only docs from the last 30 days) and hybrid search that mixes vector similarity with BM25. Examples: Pinecone, Weaviate, Qdrant, Milvus, pgvector, MongoDB Atlas Vector Search.

Why it matters

Vector DBs are the storage layer for almost every RAG and semantic-search system. The choice matters: managed vs self-hosted, hybrid search support, filter performance, metadata cardinality, and how recall degrades under load all show up in production. For smaller corpora you can skip a dedicated DB and use pgvector or even an in-memory FAISS index — this is often the right call.

Example

client.upsert(
    collection="docs",
    points=[
        {"id": "doc-42", "vector": embed(text), "payload": {"tenant": "acme", "doc_type": "policy"}}
    ],
)
hits = client.search(
    collection="docs",
    query_vector=embed("what is our refund policy?"),
    query_filter={"must": [{"key": "tenant", "match": {"value": "acme"}}]},
    limit=5,
)

You’ll hear it when

• Standing up a RAG pipeline.
• Comparing Pinecone vs Qdrant vs pgvector for a new project.
• Discussing tenancy isolation and metadata filters.
• Profiling RAG latency end-to-end.
• Debating whether you really need a dedicated vector DB at all.