Inputs
JSON, CSV, events, documents, application records, and tool output.
Architecture
From evolving operational data to shared, inspectable context.
RushDB separates the interface software uses from the fragmented stores teams usually assemble. Data enters through one write path, becomes connected and self-describing, and remains available through exact, semantic, relational, and analytical query surfaces.
Data path
One write path. Four architectural stages.
Context model
Typed records, properties, values, explicit relationships, embeddings, and live schema.
Query surfaces
Exact filters, semantic retrieval, traversal, schema inspection, selection, and aggregation.
Consumers
Applications, agents, analytical views, REST, TypeScript, Python, and MCP.
End-to-end trace
See what crosses each architectural boundary.
The write and schema responses below use one normalized checkout fixture. They show where nested input becomes records and relationships, and how the resulting structure becomes query context for SDKs, REST clients, MCP tools, and Smart Search.
01 · Create context
Import one operational fixture with explicit nested structure.
Upper-case nested keys become labels and preserve parent-child relationships. Property types and the schema surface emerge from the records that were actually written.
Request
db.records.import_json({
"label": "ACCOUNT",
"data": {
"accountId": "acme-01",
"name": "Acme Corp",
"tier": "enterprise",
"FEATURE": [{
"featureId": "checkout",
"name": "Checkout",
"EVENT": [
{ "eventId": "evt-1", "type": "conversion", "value": 129, "channel": "organic", "timestamp": "2026-07-25T09:00:00Z" },
{ "eventId": "evt-2", "type": "conversion", "value": 89, "channel": "partner", "timestamp": "2026-07-26T10:00:00Z" }
],
"INCIDENT": [{
"incidentId": "inc-17",
"status": "open",
"severity": "high",
"summary": "Checkout requests are timing out."
}]
}]
}
})What to notice
- Nesting provides the relationship source in this fixture.
- Matching identifiers in unrelated flat imports would remain ordinary fields until explicitly connected.
Inspect the model
Read the schema software will use to form queries.
The schema surface turns observed labels, typed properties, and relationship paths into machine-readable context. It is a projection of stored structure, not a separate hand-maintained schema file.
Request
schema = db.ai.get_schema_markdown({
'labels': ['ACCOUNT', 'FEATURE', 'EVENT', 'INCIDENT'],
})
print(schema.data)What to notice
- RushDB’s LMPG layer exposes property usage and relationship structure over Neo4j-backed storage.
- Read the returned Markdown rather than assuming labels or paths; schema freshness and cache behavior are deployment concerns.
03 · Agent read
Generate and execute SearchQuery from natural language.
Smart Search uses the project schema, returns the generated SearchQuery and warnings, then exposes the same record result through the SDK envelope.
Request
result = db.ai.search(
'Show open incidents connected to Acme Corp'
)
print(result.search_query)
print(result.warnings)
print(result.data)What to notice
- ai.search is natural-language query generation and execution—not direct vector similarity.
- Inspect searchQuery and warnings before trusting the execution; generated structure varies with schema and model configuration.
LMPG and Neo4j
A property-centric model on a graph storage and transaction engine.
RushDB implements its Labeled Meta Property Graph model on top of Neo4j. Neo4j provides the underlying graph storage and transaction engine. LMPG elevates properties and their usage into queryable graph structure so software can explore labels, fields, values, and relationships rather than relying only on external schema documentation.
Records and properties
Operational records retain typed fields while property usage contributes to the live structural model.
Relationships and topology
Explicit links and nested structure remain traversable alongside record queries.
Semantic indexes
Chosen property values can use managed or externally supplied embeddings while remaining attached to their operational records.
| Layer | Responsibility | Observable surface |
|---|---|---|
| Neo4j | Graph storage and transaction engine | Durable nodes, edges, indexes, ACID mechanics |
| RushDB LMPG | Property-centric data model and inferred structure | Records, HyperProperties, labels, values, relationship topology |
| RushDB APIs | Product operations and query behavior | SDKs, REST, SearchQuery, schema, vector indexes, MCP |
| Application policy | Authorization and approved product operations | Tenant scope, allowed labels, limits, result shaping |
Deployment
Keep the application surface stable across deployment models.
RushDB Cloud
Managed infrastructure for the fastest path from project creation to production queries.
External database
Connect RushDB Cloud to your own Neo4j or Aura database while retaining the RushDB API and data model.
Self-hosted
Operate RushDB with your own Neo4j instance when infrastructure ownership is the primary requirement.
Claim boundaries
Separate available product behavior from research ambition.
Clear boundaries make architecture evaluation more useful and keep product claims tied to observable behavior.
Implemented product capabilities
Typed records, live schema, property and value discovery, relationship-aware queries, managed or external embeddings, a common query shape, ACID transactions, and current analytical operations.
Configuration-dependent capabilities
Semantic retrieval requires an embedding index. Suggested relationship analysis requires a configured LLM and stays in draft until explicitly approved.
Research direction
Engine-level vector-on-edge indexing and generalized performance advantages remain research topics. The product site should not claim benchmark superiority without published empirical evidence.