Increase revenue
Recommendations from the graph
The oldest recommendation signal is still the strongest: people similar to you, choosing things you haven't seen yet. That's not a model — it's a two-hop walk through the purchase graph.
The model
The shape of the problem
Customers connect to products through orders; products connect to categories and topics. 'Customers who bought what you bought' is you → product → other customers → their products. Precomputing this in batch means recommending yesterday's behaviour; querying it as a graph means the recommendation moves the moment the data does.
Collaborative filtering, live
The classic also-bought query is a pattern match with aggregation: walk to co-purchasers, collect what they bought, rank by overlap. Runs at request time, so a purchase made a second ago changes the answer a second later.
Blend signals without a pipeline
Purchases, views, wish-lists and category tags are just relationship types. Weighting recency or de-boosting what's already owned is a WHERE clause and an ORDER BY — not a feature-store deployment.
One graph per surface
Recommendation experiments want isolation: an instance per market, per storefront, per A/B arm. Fast provisioning and per-second billing make a throwaway experiment graph an API call rather than a capacity request.
MATCH (c:Customer {id: $id})-[:BOUGHT]->(p:Product)
<-[:BOUGHT]-(peer:Customer)-[:BOUGHT]->(rec:Product)
WHERE NOT (c)-[:BOUGHT]->(rec)
RETURN rec.name,
count(DISTINCT peer) AS peers,
collect(DISTINCT p.name)[0..3] AS because
ORDER BY peers DESC
LIMIT 10Questions
Recommendations, asked directly.
Is this better than an ML recommender?
It's earlier, not better. Graph co-occurrence is transparent, live and needs no training data — the right first system, and a strong baseline any model has to beat. Teams that add ML later often keep the graph as the feature source.
Can recommendations update in real time?
Yes — that's the point of querying rather than precomputing. The traversal runs against the current graph, so new purchases influence results immediately.
How do I avoid recommending what someone already owns?
It's one line: WHERE NOT (customer)-[:BOUGHT]->(candidate). Exclusions that are painful in batch pipelines are predicates here.
What about cold-start users with no history?
Fall back to shorter paths: top products in the categories they're browsing, or what's trending in their region. Both are one-hop aggregations over the same graph.
Where does the data come from?
Order streams via Kafka, catalogue tables from Postgres or a warehouse, events from object storage. MERGE-based loads keep replays safe.
Can I run this per tenant or per store?
Yes — an instance per storefront is a supported pattern, not a workaround. Each gets its own credentials, sizing and bill.
Related solutions
Manage risk
Fraud detection
Fraud hides in relationships — shared cards, devices and addresses. Model transactions as a graph and expose rings that row-based queries can't reach.
Read moreManage risk
Identity resolution
The same person exists three times across your systems. Model records and their attributes as a graph and merge duplicates by walking what they share.
Read moreBuild with AI
Knowledge management
Documents, people, systems and decisions, connected and queryable. Full-text search finds the node; the graph explains its context.
Read moreStart now
~98.7%
token efficiency at 2,000 entities — see the footnotes above
Put your first graph up in a minute.
A free instance takes about a minute and no card. Write two MERGE statements, read them back, and you have a living graph — with provenance on every fact.
First-graph path
LiveCreate a free instance
No card. Ready in about a minute.
Connect your driver
bolt+ssc:// URI into the driver you already use.
Write two MERGEs
That's the entire shape of agent memory.
Point an agent at it
One MCP config block. No integration code.