Choosing a vector database: what matters after the benchmark

01Start with the question you are actually asking

Pure nearest-neighbour search over a static corpus is the easy case, and almost every option handles it. Real retrieval queries are compound: find documents similar to this text, belonging to this tenant, that this user is permitted to see, updated within the last quarter, excluding archived records. That is a filtered vector search, and filtering is where implementations diverge sharply.

Pre-filtering restricts the candidate set before the vector search runs, which is correct but can be slow when the filter is unselective. Post-filtering searches first and discards afterwards, which is fast but can return far fewer results than requested - sometimes zero - when the filter is selective. Understand which strategy your candidate uses, because it determines whether your permission-filtered queries return sensible results.

• Test filtered queries with your real tenancy and permission shape, not generic filters.
• Check behaviour when a filter matches very few documents.
• Confirm whether filters are indexed or evaluated by brute force.
• Verify result counts stay stable as filter selectivity changes.

02Freshness under continuous writes

Benchmarks index once and query forever. Production indexes constantly - new documents, edits, deletions, re-embeddings after a model change. Approximate nearest-neighbour indexes vary enormously in how they handle this. Some degrade in recall as segments accumulate and need periodic rebuilds. Some hold a write lock during compaction. Some make deletion a tombstone that never truly reclaims space until a full rebuild.

Ask the operational questions directly: how long until a written document is queryable, what happens to latency during compaction, and what a full re-embedding of the corpus costs in wall-clock time. That last one matters more than people expect, because embedding models get replaced and every replacement means reprocessing everything you have.

03The honest comparison

The categories below cover most decisions. The right answer depends far more on your existing operational footprint than on raw performance, because a system your team already knows how to run is worth a great deal.

04Why pgvector is the right default more often than people admit

If you already run Postgres, starting there eliminates an entire class of problems. Your vectors live in the same transaction as the row they describe, so there is no dual-write consistency gap where an embedding exists for a deleted document. Your existing backups, replication, access control, monitoring and on-call knowledge all apply. Joins against relational data - permissions, tenancy, metadata - are native rather than an application-layer merge.

The scaling ceiling is real but further away than most teams assume, and a great deal further than the corpus most products actually have. Move to a dedicated system when you have measured a specific limit you cannot work around, not in anticipation of one.

05Hybrid search is not optional

Vector similarity is excellent at semantic matching and poor at exact matching. Product codes, error identifiers, proper nouns, version numbers and acronyms are precisely the terms users search for and precisely where embeddings blur meaning. A query for a specific SKU will happily return semantically similar products and not the one requested.

Combining keyword scoring with vector similarity - typically via reciprocal rank fusion - resolves this, and the improvement is usually larger than any gain from switching vector engines. Whatever you choose must support keyword search natively or sit alongside something that does. Evaluate that before performance.