Skip to content
Start free
← All solutions

Recommendations

Relevant products.
Clear reasons.

Combine similarity, product relationships and business rules to build a shortlist your application can explain.

Start free Try vector retrieval
The recommendation recipe
  1. DiscoverSimilar and related candidates
  2. QualifyCurrent stock, price and availability
  3. OrderA ranking your application controls

From a product to a shortlist

Different signals.
One application experience.

Retrieve candidates through the vector and graph APIs, fetch their product rows, then apply your ranking. The example changes the application recipe while keeping eligibility fixed.

A sample outdoor catalogInteractive illustration
Starting productTrail runner product-9
Vector similarityDeclared accessory links

Retrieve candidates

  • Ridge runnerSimilar embedding · product-12
    In stock
  • All-weather runnerSimilar embedding · product-18
    Sold out
  • Light daypackAccessory relation · product-22
    In stock
  • Running socksAccessory relation · product-31
    In stock
Your application

Check.
Combine.
Rank.

  1. Fetch current rows
  2. Remove unavailable items
  3. Order eligible candidates

Choose a ranking recipe

  1. 01
    Ridge runnerSimilar embedding
  2. 02
    Light daypackAccessory relation
  3. 03
    Running socksAccessory relation

Sample ordering set by the application. No live query or measured scores.

Your application coordinates these requests. This is not a single cross-model query or a shared-snapshot guarantee.

See retrieval patterns

Prepare the catalog

Give each signal a record to point to.

01 · Products

The business facts

Store names, prices, stock and availability in rows. A stable product ID connects those fields to every retrieval result.

Define your schema
02 · Embeddings

What feels similar

Generate embeddings with your chosen model. Keep the dimensions and distance metric consistent across product writes and queries.

Configure vectors
03 · Relations

What belongs together

Declare accessory or category relations using record references. Your application decides which connections contribute useful candidates.

Model relationships

Eligibility before ranking

A close match still needs to qualify.

Use SQL to check retrieved IDs against the fields that determine whether a product can be shown. Keep merchandising rules separate from similarity scores.

  • Remove unavailable products.
  • Apply market and price requirements.
  • Deduplicate IDs before ordering.

Vector metadata filters use exact equality and behave differently by index. IVF-PQ does not apply them; check the index contract before relying on a filter.

Read filtering behaviour
Fetch eligible candidate rowsSQL example
SELECT id, name
FROM shop.products
WHERE id IN ($1, $2, $3)
  AND in_stock = true
  AND price_cents <= $4
LIMIT 12;

Bind candidate IDs and the budget through the request's params array.

Keep the experience current

Plan the update path, too.

Row, vector and full-text updates are separate calls. Update the affected representations when a product changes, and track any stage that needs retrying.

  1. 01

    Write the record

    Change business fields and declared relationship references.

  2. 02

    Refresh derived data

    Replace embeddings or search entries when their source content changes.

  3. 03

    Handle partial progress

    Retry failed stages and recheck purchase availability in the application.

Follow catalog ingestion

Build and evaluate

Judge the shortlist,
not just the search.

Compare recipes on representative products. Track eligible result coverage, relevance and latency across the entire application flow. Keep a curated fallback when too few candidates survive.

Retrieve the first candidatesVector quickstart Add relationship contextGraph methods and limits Review the measurementsPublished workloads and methodology

Build with OriginChainDB

Make the next suggestion useful.

Start free Talk through your workload