Turn nested JSON into a graph on write.
Most graph databases ask you to model nodes, edges, and constraints before you load data. RushDB inverts that order: you push the JSON you already have, and property types plus parent-child relationships are inferred as it arrives.
JSON-to-graph ingestion is the process of converting nested JSON objects into linked graph records automatically, so parent-child structure in the payload becomes queryable graph relationships without a separate modeling step.
What this guide covers
The practical decision points.
Nesting becomes structure
A nested object in the payload becomes a separate Record connected to its parent — the graph shape mirrors the JSON shape.
Types are inferred, not declared
Property types (string, number, boolean, datetime) are inferred from the values as they arrive.
Cross-source links stay reviewable
Parent-child links from nesting are automatic. Relationships across separate flat imports are suggested, not silently created.
Architecture sketch
From payload to graph
One importJson call decomposes nested objects into linked Records depth-first, assigns labels from the parent key, and infers property types from the values.
Implementation example
Import nested JSON in one call
The nested departments become linked Records with inferred types. No schema definition or migration runs before this write.
from rushdb import RushDB
db = RushDB("RUSHDB_API_KEY")
db.records.import_json(
label="COMPANY",
data={
"name": "Acme Corp",
"foundedAt": "2016-04-01",
"departments": [
{"name": "Engineering", "headcount": 42},
{"name": "Design", "headcount": 12},
],
},
)
schema = db.ai.get_schema_markdown({"labels": ["COMPANY", "DEPARTMENTS"]}).data
print(schema)What "automatic" actually means here
Automatic parent-child linking is a property of nested structure that already exists in the payload — RushDB is not inferring domain meaning that isn’t there. Two separate flat imports that happen to share a field name are not automatically linked; that requires an explicit relationship or an approved suggested pattern.
Nested object → automatic child Record and parent-child relationship
Two flat records sharing a field value → not linked automatically
Flat records with a reviewable shared-field pattern → surfaced as a suggested relationship, pending approval
What happens to types
Each property value is inspected as it arrives and assigned a type — string, number, boolean, or datetime. Because this happens per write, the same label can gain new properties over time without a migration; the live schema simply reflects whatever properties currently exist across that label’s Records.
What about MongoDB, Postgres, or other non-JSON sources?
Today, ingestion works over JSON and CSV pushed through the SDK or REST API — export or stream records from your existing MongoDB, Postgres, or API-based system as JSON, then push them the same way every example on this site does. Native source connectors are on the roadmap, not a shipped capability yet.
Decision table
Schema-first import vs JSON-to-graph
The practical difference shows up before the first query: how much modeling work happens before you can write data at all.
Design node labels, edge types, and constraints; write a migration or setup script.
Send the JSON payload you already have. No migration runs first.
Manually mapped to explicit node and edge creation statements.
Inferred depth-first: nested objects become child Records connected to their parent automatically.
Requires a schema migration or explicit constraint update.
New fields become visible in the live schema on the next write — no migration step.
Enforced upfront via constraints.
Optional: add a Model with field-level validation when you want guarantees, skip it otherwise.
Related RushDB docs
Read the primitives behind the guide.
These docs links are the implementation references for the concepts explained on this page.