Vector Database

Comparing a query vector against every stored vector is exact and linear in collection size, which is fine for thousands of items and hopeless for millions. Approximate nearest-neighbour indexes — HNSW graphs being the most common — build a navigable structure that reaches the neighbourhood of the true nearest vectors in far fewer comparisons. The trade-off is explicit: index parameters let you buy recall with memory and build time, or buy speed by accepting that an occasional true nearest neighbour is missed.

The feature that separates a usable store from a raw index is filtering. Real queries are rarely "find similar text" alone; they are "find similar text belonging to this tenant, in this locale, not archived". A store that applies predicates during traversal returns a full result set, whereas one that filters afterwards can return almost nothing once a selective filter is applied. Namespaces, payload indexes and hybrid keyword scoring exist to make that path work.

The choice people over-think is which vector database to adopt; the choice they under-think is whether they need a separate one at all. A PostgreSQL extension keeps vectors in the same transaction, the same backup and the same access-control model as the rest of the data, and removes an entire class of synchronisation bugs. A dedicated service earns its operational cost when the index outgrows what you want to run beside your transactional workload — not before.