Every vector database sells the same promise: fast nearest-neighbour search over millions of embeddings. The differences that matter show up under load — when the index no longer fits comfortably in memory, when you need to filter by metadata and similarity at once, and when 'approximate' quietly starts dropping the results you needed.
Approximate search is a knob, not a default
HNSW and IVF indexes trade exactness for speed, and their parameters directly set that trade. A higher search breadth improves recall at the cost of latency; a smaller one is fast but skips real neighbours. The only responsible way to pick these numbers is to measure recall against an exact brute-force baseline on your own data, not to accept the library defaults.
- Benchmark approximate recall against exact search on a real query sample.
- Tune the accuracy-versus-latency parameters to your p95 latency budget, not a generic default.
- Rebuild or retrain the index after large writes — stale graphs degrade recall.
Filtering and similarity have to work together
Real queries are rarely pure similarity. You want the nearest chunks belonging to this tenant, in this language, updated this year. If the database filters after the vector search, it can return an empty set even when matching documents exist, because they fell outside the approximate candidate list. Prefer engines that apply metadata filters during traversal, and model your metadata for the filters you actually run.
Do you even need a separate database
For many workloads, pgvector inside the Postgres you already operate is the right answer. You keep transactions, joins and one backup story instead of adding a system to run and sync. Reach for a dedicated vector store when scale, sharding or specialised index types genuinely demand it — not because it is the fashionable box on the architecture diagram.
- Start with pgvector if your corpus fits and you already run Postgres.
- Move to a dedicated store when index size, write throughput or filtering outgrow the database.
- Keep the embedding pipeline reproducible so you can re-index into a new store without a migration nightmare.