solution · recommendations

Vector + graph + SQL filters. One query.

Most stacks split these into three systems and pay the integration tax. We compose them inside one plan, against one consistent snapshot.

what real recommendations need

Vector similarity

Find items like this one. Four metrics × four index variants.

Graph signal

Who bought this also bought that. PageRank, connected components, triangles.

SQL filters

In stock, in region, in budget. Predicate pushdown to secondary indexes.

why one query matters

Filtering after kNN is a recall hole.

Three systems means three options, all bad: filter before kNN (your vector DB doesn't know your inventory), filter after kNN (recall collapses when most of your top-k fail the filter), or oversample blindly (latency tanks).

One plan means one decision boundary. Adaptive over-fetch widens the candidate pool just enough to keep k survivors after the predicate.

request

POST /v1/tenants/:t/vector/search
{
  "schema": "products",
  "k": 12,
  "dense":  { "vector": [...], "metric": "cosine" },
  "where":  "in_stock = true AND region = 'IN'",
  "graph":  {
    "rerank_by": "pagerank",
    "schema":   "co_purchase"
  }
}

adaptive over-fetch

When a query carries a WHERE clause, the optimiser widens the kNN candidate pool just enough to leave k survivors after the predicate. Recall stays at target; you don't pay full-table-scan latency.

deferred

post-1.0Multi-vector reranking.
not usOnline learning feedback loop. Train your model, push the new embeddings to us.

See the vector + graph surface.

Vector docs → Graph docs Try it