Vector Databases

A vector database stores embeddings and answers one question fast: what is closest to this?

That is similarity search. Keyword search still matters. This is the extra index for meaning.

Purpose and functionality

I need four things, nothing mystical:

• Store a vector plus metadata (doc id, source, tenant, timestamp)
• Indexing embeddings so queries stay fast as the set grows
• Performing similarity search with a distance metric (cosine is the usual choice)
• Filter by metadata so one customer never sees another customer’s chunks

Pick one

I do not run six of these. I pick one and learn its failure modes.

• Chroma — local and simple. My default for a prototype on my laptop.
• Pinecone — hosted, when I do not want to operate the index.
• Weaviate — when I want a fuller database, not only nearest neighbor.
• FAISS — a library, not a server. Fast local search inside a Python process. You bring your own storage and filters.
• LanceDB — embedded, file-based. Useful when I want vectors next to the app without a new cluster.
• Qdrant — a dedicated engine I consider when filtering and performance are the reason Postgres feels tight.
• Supabase — Postgres plus vectors, which I like when the rest of the app is already there.
• MongoDB Atlas — reasonable if the product is already on Atlas and I refuse to add another datastore.

How I implement search

1. Chunk and embed offline, or when the source document changes
2. Upsert { id, vector, metadata }
3. Embed the user query with the same model
4. Query top-k with a metadata filter
5. Send those chunks to the chat model, not the raw vectors

If top-k looks irrelevant, I fix chunking and metadata before I blame the database.

Next

Retrieval only matters once a generator has to answer from it:

• RAG and Knowledge Systems