April 4, 2026

Why we put friends and badges in a Neo4j knowledge graph

"Find users in my cohort across both BudBrain and WineBrain whose top 5 cannabis ratings overlap mine, then look at what wine they all rated 5 stars" is one query. In SQL it's a horror show of joins. In Cypher it's six lines.

So we keep both. PostgreSQL is the source of truth — every account, profile, rating, friendship, share. Neo4j is a derived index, refreshed nightly by a sync job. Account, TenantProfile, Item, Brand, Strain, Varietal, Cohort nodes; RATED, IN_COHORT, FRIENDS_WITH, BY_BRAND, OF_VARIETAL edges.

We run the graph on alternate ports (HTTP 7475, Bolt 7688) so it can coexist with any default-port Neo4j you already have on the host. The sync is idempotent (every write uses MERGE), so re-running is safe.

Three queries it powers really well:

1. Cohort overlap across brands — find peers in your same cluster who rate things you've rated. 2. Cross-brain pairings — for your top cannabis strains, what wine varietals do your cohort peers rate highly? 3. Brand affinity within a cohort — which brands punch above their weight for the type of user you are?

The platform model means WineBrain's launch automatically gets a richer graph just because BudBrain users exist.

← All posts

Why we put friends and badges in a Neo4j knowledge graph — X-Brain blog