Vector databases for job matching

At tens of thousands of vectors, similarity search in your existing database is fast enough and vastly simpler to operate. A dedicated vector store adds a system to deploy, monitor, back up and keep in sync with your source of truth.

That synchronisation is the hidden cost. Two stores means two truths, and reconciling them after a partial failure is work nobody plans for. Postgres with a vector extension keeps jobs and their vectors in one transaction, which removes the whole class of problem.

The failure it removes is the one candidates notice. A posting closing in the primary database while its vector remains in a separate index produces search results pointing at roles that no longer exist, and that reconciliation gap is exactly where a two-store architecture leaks.

Dedicated stores earn their place at genuinely large scale, with high query concurrency, or when you need index features your database does not offer. Millions of vectors with heavy concurrent search is a real reason.

Latency pressure is another: if you are serving matches interactively and your database’s index cannot hold the tail latency, that is measurable and worth acting on. Migrate on a measurement, not on an expectation.

There is an intermediate step worth taking first, and it is usually enough: a read replica dedicated to matching. It removes the contention that triggers most of these thresholds without introducing a second data model or another system to operate.

Job matching is never pure similarity. It is "similar, and in this country, and active, and within this seniority band" — and how a store combines filters with vector search differs enormously.

Filtering after retrieval is the trap: request the top hundred, filter by country, and be left with three because the other ninety-seven were elsewhere. You need pre-filtering or filtered search, and this single property should drive the choice more than raw benchmark speed.

The awkward middle case catches people even in stores that support filtering. A filter selective enough to matter but not enough to change the plan leaves the approximate search exploring candidates the filter then removes, so it returns fewer results than requested — which looks like a thin market rather than a query problem.

• Does it filter before or after the similarity search?
• Can it combine several filters without collapsing recall?
• Does it support updating metadata without re-inserting the vector?
• How does it behave when a filter matches very few rows?

Jobs expire constantly, and an index serving filled roles is worse than useless — candidates lose trust quickly after two dead links. Deletions must propagate promptly, which many vector setups treat as an afterthought.

Prefer soft-deleting with an active flag and filtering on it, then reclaiming space periodically. Immediate hard deletes from an approximate index are often expensive and sometimes incomplete.

Inserts need the same urgency in the other direction. A posting that becomes searchable six hours after publication is a posting the early applicants already took, so embed on insert and run a sweeper for whatever the insert path missed.

You will change the embedding model or the chunking, and when you do, every existing vector becomes incomparable with new ones. Mixing the two generations silently produces plausible nonsense rather than an error.

Store the model identifier and chunking version with every vector, and make the active version part of the query rather than a column somebody remembers to filter on. A query that cannot return the wrong generation cannot mix them.

Support running two generations side by side during the migration. A store that forces a single index makes the choice between a costly big-bang re-embed and never improving, which is how a system freezes on the model it launched with.

Approximate nearest-neighbour indexes trade recall for speed, and the defaults are rarely right for your data. The important thing is knowing what you gave up: measure recall against an exact search on a sample before and after tuning.

Teams that tune for latency without measuring recall end up with a fast system that quietly stops returning the best matches — which is indistinguishable from a matching algorithm that got worse, and far harder to diagnose.

Track that number over time rather than measuring once. Recall drifts as the data distribution changes, and a parameter that was right at fifty thousand vectors is not necessarily right at five hundred thousand.

Plan the build cost too. Index construction on a large table is heavy enough to interfere with normal write traffic, so it belongs in a maintenance window rather than in whatever moment someone decided to try a new setting.