Vector stores 101

FAISS, pgvector, and Qdrant do the same core job differently — here's the cheat-sheet for picking one.

Why it matters

Searching for the k-nearest vectors by brute force means comparing your query against every stored vector — fine for 10,000 chunks, unusable at 50 million. A vector store solves this with an approximate nearest-neighbour (ANN) index (commonly HNSW, a navigable small-world graph) that finds almost the true nearest neighbours in a fraction of the time, trading a small amount of recall for a large amount of speed.

The three tools you'll meet constantly differ in where they live, not in the core algorithm:

• FAISS is a library, not a database — it runs in-process, has no persistence or server of its own, and is the fastest option for research or a single-machine prototype.
• pgvector is a Postgres extension: you get ANN search inside your existing relational database, so a single SQL query can filter by WHERE customer_id = 42 and rank by vector distance in one shot — ideal when your metadata already lives in Postgres.
• Qdrant (like Pinecone, Weaviate, Milvus) is a purpose-built vector database with its own server, rich metadata filtering, and horizontal scaling — the right choice once you outgrow a single Postgres instance or need production features like replication.

The decision that's hard to reverse is metadata filtering: if you need 'find similar chunks, but only from documents tagged region=EU and updated after 2024', pick a store that filters before the ANN search, not after — filtering after ranking can return zero results even when good matches exist.

A vector store indexes embeddings for fast approximate-nearest-neighbour (ANN) search. The exact search is O(N) per query; ANN structures (HNSW graphs, IVF lists) trade a little recall for orders-of-magnitude speed.

Choosing one is mostly about operational fit, not benchmarks:

The decision that bites later is metadata filtering. Production retrieval is almost never pure similarity — it's 'nearest chunks where tenant = X and doc_version = current and acl allows viewer'. A store that filters before ANN (not after) keeps recall correct under tenancy. Picking a store with weak filtering is a one-way door: you discover it only once multi-tenant traffic arrives.

Sizing intuition. HNSW gives great recall/latency but holds the graph in RAM — memory grows with vector count × dimensions. IVF is cheaper on memory but needs a good nprobe. Know which one your store uses before you promise a p95 latency.

A vector store is a warehouse with a layout strategy. FAISS is a bare floor where you sprint fastest but there are no shelves, locks, or inventory list. Qdrant is a managed warehouse with aisles, access badges and a manifest. pgvector is a shelf you bolted onto the office you already rent. You don't pick by top speed — you pick by what the building has to survive.

• Choosing by benchmark screenshot. Fix: choose by filtering, tenancy and backup needs first.
• Post-filtering after ANN. Symptom: empty results under tenant filters. Fix: a store that filters during ANN.
• Forgetting memory cost of HNSW. Symptom: OOM at scale. Fix: capacity-plan RAM = vectors × dims × bytes.
• No reindex story. Symptom: stuck on an old embedding model. Fix: design dual-index / shadow reindex from day one.