A recommender built on pgvector

The obvious design gives each candidate a single profile vector and finds the nearest jobs. It works, and it blurs someone with a backend history and a recent move into data engineering into an average that is neither.

Keep several vectors per candidate — one per substantial role, plus one for their stated target if they gave you one — and query with each. A person changing direction is then served by the target vector rather than dragged back by their history.

Merging the result sets is straightforward and worth doing deliberately. Take the union, keep each posting’s best distance across the candidate’s vectors, and record which vector produced it — that last field is what lets the feed explain itself and what lets you debug a feed that has drifted.

History describes where someone has been; the stated target describes where they want to go. A recommender that weights these equally will keep showing a career-changer the field they are leaving, which is the single most common complaint about job feeds.

Give explicit intent a higher weight, and decay older roles. Someone’s work from six years ago should influence the feed less than what they did last year, and far less than what they said they want.

Behaviour needs the same treatment. Clicks from three months ago describe a search that may have changed direction since, and weighting recent interaction above old interaction is what lets the feed follow a candidate rather than anchoring them.

• Explicit target role — highest weight
• Recent roles — moderate weight, decayed by age
• Older roles — low weight, retained for transferable signal
• Recent searches — session-level, applied at re-rank time

This is the reason to be in Postgres at all. Active postings, in eligible countries, in the right employment type, ordered by distance to the profile vector — one statement, one plan, no reconciliation between systems.

Check the plan rather than assuming. When the filter is highly selective, an exact scan over the filtered subset can beat the approximate index on both speed and accuracy, and the planner may or may not choose it for you.

The case that catches people is a filter selective enough to leave few rows but not selective enough for the planner to abandon the vector index. The approximate search then explores candidates that the filter subsequently removes, and returns fewer results than requested — which looks like a thin feed rather than a query plan problem.

New postings need embeddings before they can be recommended, and a posting that becomes searchable six hours late is a posting the early applicants have already taken. Embed on insert where you can, and run a sweeper for whatever the insert path missed.

The same sweeper should handle profile changes. A candidate who updates their target role and sees the same feed the next morning concludes, reasonably, that the product ignored them.

Make the sweeper idempotent and give it a queue rather than a scan. A pending-embedding flag on the row, processed in batches with retries, handles a provider outage gracefully; a nightly full table scan hides the backlog until someone notices postings missing from search.

An approximate index trades recall for speed, and the trade is set by parameters most teams configure once and never revisit. As the table grows and the data distribution shifts, the same settings return a steadily worse approximation of the true nearest neighbours.

Nothing surfaces this on its own. Queries stay fast, results stay plausible, and the feed quietly gets worse — which gets attributed to the model, the weighting or the market before anyone suspects the index.

The check is cheap: on a sample of candidates, run the query with the index and again with the index disabled, and compare the overlap in the top results. Track that number over time and treat a fall in it as a regression, because that is what it is.

Build cost is the other consideration. 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 tune a parameter.

Recommendations for the home feed can be computed on a schedule and stored, which makes serving a primary-key lookup. Store the generation timestamp and the model version alongside them, so a strange feed can be diagnosed rather than guessed at.

And periodically compare the approximate results with an exact scan on a sample. An index quietly losing recall looks exactly like a recommender that got worse, and only this comparison tells the two apart.

Precomputation needs an invalidation rule or it becomes the stale thing it was meant to optimise. A profile change, a new target, or an application submitted should all mark the feed for regeneration rather than waiting for the next scheduled run.