Choosing a Vector Store

Two teams choose a vector store on the same day. Team A opens five vendor feature matrices, finds the same ten checkmarks on all of them, and argues for a week. A feature matrix answers can it; the decision is about does it fit this workload, run by these people, at this price. So the spec comes first, and it fits on one page.

Worked example, used through the rest of this topic — a support assistant:

12M tickets, 1536-dim embeddings        40 QPS peak, p95 <= 80 ms
filter: tenant + status on every query   results joined to tickets row for display
deletion: tenant offboarding <= 1 hour    team: 2 engineers, already run Postgres

Three lines constrain the field: the join requirement and existing Postgres operation pull toward Vector Search with pgvector, while the one-hour deletion and the absence of anyone eager to run a new system pull the other way. Conversation history stays relational too (Conversation History), so what you choose here is a derived index — and derived things are replaceable.

write spec ──> constraints ──> eliminate ──> score ──> prototype two ──> decide
 (1 page)     (hard: joins,   (anything     (weights   (your queries,   (document
               retention)      failing)      not checks) your filters)    the weights)

Hard constraints — retention, isolation, latency ceiling — eliminate before preferences score.

The five recurring stores do the same core thing — approximate nearest-neighbor over filtered vectors — and differ on four axes: relation to your relational source, filter behavior, who operates it, where it stops scaling.

The failure modes this stage produces are consistent enough to list:

• Scoring features instead of constraints. A matrix cannot express nobody on the team runs Kubernetes — that sentence eliminates a candidate faster than any benchmark.
• Benchmarking on random vectors with no filters. Every store looks fast until filters arrive, and filter selectivity is where implementations diverge.
• Reading storage price alone. pgvector rides a database you already pay for while serverless bills per request and per GB; the curves cross at different volumes, so price at projected volume.
• Counting checkmarks. Two stores that both tick metadata filtering differ by an order of magnitude when the filter matches 2% of the corpus, and no cell shows that.
• Skipping the ownership question. The cheapest line is the one nobody pages for; the most expensive is the one adopted because a benchmark said so.

A weighted matrix turns the argument into arithmetic: score each criterion 1–5, multiply by a weight, sum. Scores are opinions about products; weights are facts about your organization — and they decide the outcome far more.

Scenario A — the spec above, SQL joins non-negotiable:

Scenario B — an offline analytics index at 400M vectors, no joins, platform team staffed:

Now shift one weight: ops burden 0.20 to 0.05 (platform team staffed), that 0.15 to scale headroom:

pgvector 3.85   Pinecone 3.90   Qdrant 3.85   Milvus 3.75

The scores never changed; one weight flipped the leader and left the top three within a point of each other — the method working as intended, because the matrix exists to show which assumptions the decision rests on. A near-flip means the candidates are tied on what you currently believe, and the next chapter replaces belief with measurement. A matrix that cannot be flipped by honest weights was reverse-engineered from a decision already made.

Feature lists predicted parity and the matrix predicted a near-tie. What breaks the tie is your data, your filters, and your latency budget — so the prototype is a measurement protocol, not a sandbox.

Sample: 500 queries pulled from production logs (or written by whoever wrote the requirements), each carrying its real filter. Synthetic vectors with no predicates measure the wrong thing — that is precisely the benchmark failure listed in the previous chapter.

Measure, per candidate:

Two candidates, five numbers each, pass lines written before the runs so a slow result cannot be argued into a pass. Cost Budgeting models the projected column; the deletion and backfill drills are the mechanics from Index and Collection Operations executed for real against each candidate.

The exit path is not pessimism, it is architecture. Keep the source of truth relational — rows with stable ids, the text the embeddings came from, and the embedding model version recorded per row — and the vector store remains a derived index you can rebuild with a scan and a batch job. Embedding Models covers why the model version has to be stored with the vector. With that in place, a wrong choice costs a migration measured in days (dual-write, backfill, shadow reads, ramp), while a choice made without a spec or a prototype costs a quarter of arguing about checkmarks.