Vector Database for Recommendations

Classical recommender systems split into two camps. Collaborative filtering finds people who behaved similarly to you and recommends what they liked — powerful, and useless for a brand-new item nobody has interacted with. Content-based filtering recommends items similar to ones you’ve engaged with, based on their attributes — works for new items, but historically depended on manually tagged metadata.

Item-to-item.

The simplest and most robust recommendation engine pattern. Embed every product, and when someone views one, retrieve its nearest neighbors. This powers “similar products,” “you might also like,” and related-item modules. It requires no user history at all, which makes it the right starting point — most teams underestimate how far this alone gets them.

User-to-item.

This recommendation engine pattern represents the shopper as a vector — commonly a recency-weighted average of the items they’ve engaged with — then retrieve products near that point. This is personalization proper, and it’s how a homepage or a category page adapts per visitor. Our vector search personalization guide covers the mechanics in an ecommerce context.

Two-tower models.

The sophisticated recommendation engine option, built on the approximate-nearest-neighbor retrieval described in the HNSW paper: train two neural networks, one encoding users and one encoding items, so that users land near products they’ll engage with. This captures patterns simple averaging misses — brand affinity, price sensitivity, substitution behavior. It also requires training infrastructure and enough behavioral data to learn from, which is why most teams should earn their way to it rather than start there.

A recommendation engine needs filtered retrieval, always.

Every real recommendation carries constraints: in stock, ships to this region, not already purchased, not the item currently being viewed, within a price band. Combining filters with approximate nearest-neighbor search is the hard part of this workload, and implementations diverge sharply. Qdrant leads here with rich payload filtering that holds latency under complex constraints, where some systems slow 2–3×. Weaviate also performs well.

High write throughput matters more here than in search.

A recommendation engine generates constant writes. User vectors change constantly — every click and purchase shifts them. A recommendation engine updating profiles in real time generates far more writes than a search index does. Milvus handles the highest write throughput thanks to its distributed architecture; Qdrant and Pinecone follow, while lighter systems struggle under write-heavy loads. Our real-time indexing guide covers why this matters.

Multi-vector support.

Products often need several embeddings — text, image, behavioral — and recommendation quality improves when you can query across them or combine them. Not every platform supports this natively.

Low latency at the tail.

Recommendations render inline with a page, so p99 matters more than the average. A recommendation module that’s usually fast and occasionally slow degrades the whole page.

Metadata richness.

You’ll filter and boost on business attributes constantly. Payload flexibility saves a lot of workaround code.

Run a permanent holdout.

A slice of traffic that never sees recommendations, compared on conversion and revenue per session. Not a launch test — permanent, because quality drifts as catalogs and models change.

Measure incremental revenue, not attributed revenue.

Attribution counts every purchase that followed a recommendation click, including ones the shopper would have made anyway. The holdout tells you the difference, and it’s usually smaller than attribution suggests.

Track diversity.

Distinct items recommended across sessions, and how concentrated recommendations are on your top products. A falling number signals the filter bubble tightening.

Segment by new versus returning.

Expect little effect on first-time visitors and clear lift on repeat traffic. Any other pattern means your cold-start fallback or your weighting is miscalibrated.

Watch p99 latency.

Recommendation modules that slow a page cost more than they earn.

Product detail pages

carry the highest-intent recommendation traffic. The shopper is already considering something specific, so item-to-item similarity works well, with the caveat that “similar” must not mean “the same product in another color.”

Cart and checkout

need complements rather than substitutes. Recommending another laptop to someone buying a laptop is worse than useless; recommending a sleeve or a dock is the point. This requires modeling complementarity, which pure similarity retrieval doesn’t capture — items bought together sit far apart in embedding space, since a laptop and a sleeve aren’t semantically similar at all.

Homepage and category pages

are where user-to-item personalization earns its keep, because there’s no item context to anchor on. This is also where cold-start handling shows most visibly.

Post-purchase and email

operate on a different timescale, where long-term taste vectors matter more than session signals.

Empty search results

are an underused recommendation surface. A shopper who hit a dead end has declared intent and has nowhere to go — retrieving semantically near items turns an exit into a second chance.

Co-purchase embeddings.

Train embeddings from basket data rather than content, so items frequently bought together end up close. This captures complementarity directly but needs transaction volume and suffers cold start for new items.

Dual-space retrieval.

Maintain both a content embedding and a behavioral embedding per item, and query the appropriate one per surface — content similarity on product pages, co-purchase on the cart.

Category-aware rules on top of retrieval.

Retrieve semantically, then filter or boost by category relationship rules. Less elegant, works immediately, and requires no additional training data — which makes it the sensible starting point for most teams.

Week 1 — ship the simplest recommendation engine: item-to-item only.

Embed your catalog and ship “similar products” on product detail pages. No user data required, no cold-start problem, and it typically delivers the largest single increment. Teams routinely skip straight to personalization and leave this easier win untouched.

Week 2 — business rules and filtering.

Exclude out-of-stock items, the currently viewed product, near-duplicate variants, and anything already in the cart. Unglamorous, and it’s the difference between a recommendation engine that looks intelligent and one that looks broken.

Week 3 — session signals.

Build a lightweight session vector from the last few interactions and use it on the homepage and category pages. Works for anonymous visitors, which is most of your traffic.

Week 4 — measurement.

Stand up a permanent holdout and start reporting incremental conversion and revenue per session. Do this before adding sophistication, because without it you can’t tell whether the next thing you build helps.

Beyond:

long-term taste vectors, complementarity modeling, and two-tower models — each earned by data showing the simpler layer has plateaued.

Can you build a recommendation engine on a vector database?

Yes, and it’s now a common architecture. Items and users are represented as embeddings in the same space, so retrieving recommendations becomes a nearest-neighbor query. This handles cold-start items well and runs in real time, unlike the batch pipelines classical collaborative filtering required.

Which vector database is best for recommendations?

Prioritize filtered-search performance, write throughput, and tail latency rather than raw benchmarks. Qdrant leads on filtered retrieval under complex constraints, Milvus on write throughput at scale, and Weaviate offers strong hybrid capability. pgvector works well below a few million vectors if you already run Postgres.

How do vector recommendations handle new users?

Poorly, unless designed for it — a first-time visitor has no vector. Good implementations fall back to popularity, category context, and session signals that build within two or three interactions. Since many sessions are new or anonymous, this fallback path deserves real attention.

What’s the difference between item-to-item and user-to-item recommendations?

Item-to-item retrieves products similar to one being viewed, requiring no user history — this powers “similar products” modules and is the most robust starting point. User-to-item represents the shopper as a vector and retrieves products near it, which is personalization proper and requires behavioral data.

Do vector recommendations create filter bubbles?

They can. Recommending only what resembles past behavior narrows discovery over time and suppresses serendipity. Counter it with deliberate exploration — reserving a slice of recommendations for diverse items — and measure result diversity alongside click-through.

How do I measure whether recommendations are working?

Run a permanent holdout group that never sees recommendations and compare conversion and revenue per session. Measure incremental rather than attributed revenue, since attribution counts purchases shoppers would have made anyway. Track diversity and p99 latency as guardrails.