Some questions are only answerable a few hops out.
A single-hop question — "which orders belong to this customer" — is a simple join. A multi-hop question — "which other accounts share a device with any account connected to this alert" — gets harder with every added hop, until it stops being a reasonable SQL query at all.
Multi-hop analytics is the practice of querying relationships several steps removed from a starting record — such as accounts connected through shared devices, or products connected through a shared supplier — using graph traversal instead of a growing chain of SQL joins.
What this guide covers
The practical decision points.
Depth is the problem, not the first hop
One join is routine. Three or four joins deep, with each hop fanning out, is where SQL query plans and readability both degrade.
Graph traversal treats depth as a first-class operation
Relationships are traversed as connected Records, not reconstructed through repeated joins on foreign keys.
This shows up across very different domains
Fraud rings, supply chain disruption, and GraphRAG retrieval are all the same underlying shape: follow a relationship, then follow it again.
Architecture sketch
Following a relationship more than one step
Each hop in a multi-hop query follows an explicit relationship from the previous result — no reconstructed join path, and no join count that grows with each added hop.
Implementation example
Traverse from an alert to indirectly connected accounts
The where clause traverses a relationship from ACCOUNT to DEVICE and back to other accounts sharing that device — one query, not a chain of joins.
from rushdb import RushDB
db = RushDB('RUSHDB_API_KEY')
connected_accounts = db.records.find({
'labels': ['ACCOUNT'],
'where': {
'DEVICE': {
'ACCOUNT': {'flagged': True}
}
},
})Where multi-hop questions actually show up
This is not a niche pattern — it is the same underlying shape across very different blueprints already on this site.
Fraud investigation: which accounts share a device or beneficiary with a flagged account
Supply chain: which products and warehouses are affected by a delayed supplier
GraphRAG: which cited sources and entities are connected to a matched document chunk
Agent harness portability: which prior runs and tool outputs are connected to a current session
What this does not claim
Multi-hop traversal in RushDB is nested relationship filtering within a SearchQuery, scoped to the relationships that exist in your data. It is not an unbounded graph-search algorithm, and traversal depth and performance still depend on how your data is modeled and how many hops a given query actually needs.
Decision table
SQL joins vs. relationship traversal at depth
The gap between the two approaches is small at one hop and grows sharply as more hops are added.
A single join — straightforward and performant.
A single relationship filter — equally straightforward.
Each added hop is another join; the query grows harder to write, read, and reason about.
Each added hop is another nested relationship filter in the same where clause — the query shape doesn’t change with depth.
Adding a new relationship type often means a new join and a new foreign key to maintain.
A new relationship type is a new nested key in the where clause against the current live schema.
A four-way join is hard for a reviewer to mentally trace back to the business question.
Nested relationship filters mirror the traversal path being asked about.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.