Relationship suggestions

Suggested relationships. Approved by you.

RushDB can analyze the labels, properties, and existing edges in a project and suggest relationship patterns worth making explicit — such as ORDER PLACED_BY CUSTOMER after a flat import. Analysis proposes graph structure; approval is the step that changes relationships.

Start free View docs

Flat imports leave domain relationships implicit.

Data imported from separate flat sources repeats matching keys — customerId on orders, deviceId on sessions — but nothing turns those repeated keys into traversable relationships. Writing that join logic by hand for every source pair is exactly the modeling work a schema-flexible database is supposed to remove.

Before

Matching keys across flat imports stay unconnected
Default import edges carry no domain meaning
Cross-source joins are hand-written per source pair
Schema evolution silently invalidates old join logic

With RushDB

Analysis surfaces candidate patterns with confidence and rationale
join_pattern mode creates relationships from matching keys
retype_existing_relationship mode upgrades default import edges to domain types
Nothing changes the graph until a pattern is approved

What it enables

Graph enrichment with a human approval boundary.

Each suggestion records its source, target, type, direction, mode, confidence, and rationale, and moves through an explicit lifecycle: suggested, then approved, ignored, or deleted. Deleting with deleteExisting also removes relationships the pattern materialized.

Useful after imports and schema changes

Run analysis when new flat sources arrive or the schema evolves, and stable domain relationships surface as reviewable candidates.

Two explicit modes

join_pattern creates relationships by matching keys between records. retype_existing_relationship replaces default import edges with an explicit domain type.

Reversible by design

Ignore a suggestion without changing anything, or delete an approved pattern along with the relationships it created.

How it works

Start with the smallest useful path.

Queue an analysis

Trigger analysis after an import or schema change, then poll the pattern list until the analysis status returns to idle.

Review each candidate

Inspect the proposed source, target, relationship type, direction, mode, confidence, and rationale before deciding.

Approve, ignore, or delete

Approval applies the pattern. Ignoring dismisses it without changes. Deleting with deleteExisting also removes materialized relationships.

Flow

From analysis to approved structure

The lifecycle keeps inference and mutation separate: RushDB analyzes and stores patterns as suggested; your review is what applies them.

Queue analysis

Patterns stored as suggested

Review confidence + rationale

Approve or ignore

Relationships applied

Implementation sketch

Analyze, review, approve.

Analysis runs asynchronously — queue it, poll the list, then approve the patterns that match your domain. Requires an LLM configured on the RushDB server; omit the LLM environment variables to disable suggestions entirely.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

# Queue analysis, then poll list() until analysis.status returns to "idle"
db.relationships.patterns.analyze()

result = db.relationships.patterns.list()
for pattern in result.data['patterns']:
    print(pattern['id'], pattern['type'], pattern['confidence'])

# Approval is the step that changes relationships
db.relationships.patterns.approve(pattern_id)

Know the operational boundary.

Approval is the mutation boundary

Suggested patterns never change graph meaning silently. A pattern only affects relationships once someone approves it, and deletion can roll back what it created.

Read the suggested patterns guide

Requires a configured LLM

Relationship analysis uses the LLM configured on your RushDB server. Self-hosted deployments set RUSHDB_LLM_API_KEY and RUSHDB_LLM_MODEL, or omit them to disable suggestions.

See the prerequisites

Read the suggested patterns guide

Related guides

Go deeper on the concept.

These guides explain the product category and implementation tradeoffs behind this feature.

Guide

Ontology-Aware Querying

Let agents query using the real labels, properties, and relationship paths in your data, discovered from a live schema instead of a hand-maintained ontology doc.

Read guide

Guide

JSON to Graph Database

Turn nested JSON into a queryable graph without designing a schema first. See how property types, parent-child links, and live schema are inferred on write.