Case study: analytical workloads
From event firehose to explainable business insight.
Use one connected substrate for operational events, dashboard metrics, cohort drill-downs, and the records that explain why a KPI moved.
A dashboard can show a drop without explaining it.
Events land in one system, incidents in another, and account context somewhere else. Teams see a conversion dip, then spend the next hour rebuilding the surrounding story manually.
Before
- Metrics and operational context live in separate stores
- Dashboard cards stop at the chart
- Root-cause analysis starts with manual joins
- Client code receives unvalidated query shapes
With RushDB
- Events, accounts, features, and incidents stay queryable together
- Time-bucketed metrics run in the query layer
- Drill-downs retrieve connected operational context
- Backend endpoints expose validated query builders
Graph intelligence on ingest
Incoming data becomes queryable graph context.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsData model
One flexible graph for the workflow.
Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.
Events can be grouped as metrics while still linking back to accounts, features, cohorts, and incidents.
{
"eventId": "evt-2026-05-11-001",
"type": "conversion",
"timestamp": "2026-05-11T09:00:00Z",
"value": 1,
"ACCOUNT": { "accountId": "acme-01", "plan": "pro" },
"FEATURE": { "featureId": "checkout", "surface": "web" },
"COHORT": { "cohortId": "new-signups-q2" },
"INCIDENT": { "incidentId": "inc-17", "summary": "Elevated checkout tickets" }
}Working example
Click the conversion dip. Retrieve the context.
The dashboard groups conversion events by day. A drill-down can then connect the affected interval to the feature and incident records that belong in the investigation.
EVENT conversion
timestamp: 2026-05-11T09:00:00Z
accountId: acme-01
featureId: checkout
value: 1
INCIDENT inc-17
featureId: checkout
summary: elevated support tickets during checkout{
"labels": ["EVENT"],
"where": { "featureId": "checkout" },
"select": {
"day": { "$timeBucket": { "field": "$record.timestamp", "unit": "day" } },
"totalValue": { "$sum": "$record.value" },
"events": { "$count": "$record" }
},
"groupBy": ["day", "$record.type"],
"orderBy": { "day": "asc" }
}[
{ "day": "2026-05-10", "conversions": 184 },
{ "day": "2026-05-11", "conversions": 97, "related_incident": "inc-17" }
]TypeScript SDK
Aggregate first. Drill into context second.
The metrics path stays explicit and label-scoped. Build a small server endpoint for each approved drill-down instead of passing raw query JSON from the browser.
Implementation blueprint
Build the connected analytics path.
Use this sequence to move from event ingest to KPI cards, cohort drill-downs, and connected operational explanations.
- 01Import EVENT, ACCOUNT, FEATURE, and INCIDENT records
- 02Attach events to accounts, features, and incidents when the relationship is known
- 03Build server-owned metric endpoints with select, groupBy, and time buckets
- 04Build drill-down endpoints that retrieve connected evidence
- 05Generate summaries only from the returned evidence payload
Build path
- Use EVENT records for metric calculations and cohort breakdowns.
- Connect EVENT records to FEATURE, ACCOUNT, and INCIDENT records for investigation context.
- Keep dashboard clients behind validated server endpoints.
- Present connected records as evidence, not automatic causality.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
Select expressions
Compute counts, sums, averages, collected records, and time buckets directly in SearchQuery.
Open docsgroupBy
Pivot operational records into KPI rows, cohort breakdowns, and dashboard drill-down dimensions.
Open docsRelationships
Keep KPI events connected to accounts, features, incidents, and other operational context.
Open docsHow it works
Build the smallest useful workflow first.
01
Ingest operational records
Store the event stream and the account, feature, campaign, invoice, or incident records needed for investigation.
02
Calculate focused metrics
Use select, groupBy, and time buckets for dashboard cards and trends.
03
Expose validated drill-downs
Translate a user action into a server-owned query that returns the connected context for one investigation path.
Know where it fits.
Metrics plus context
The practical outcome is not automatic causality. It is faster investigation because the KPI and relevant operational records share a queryable graph.
Keep the client constrained
Expose typed API endpoints with server-side limits. Do not let dashboard clients send arbitrary database query JSON.
Questions developers ask.
Next step