Conventional stack
- Current application state in an operational database
- Metrics in a separate flattened model
- Relationships removed during export
- Schema drift discovered after a pipeline fails
- Root-cause joins rebuilt by hand
Solution · Operational analytics
Analyze the context while it is still operational.
Query counts, groupings, value distributions, relationship patterns, entity timelines, and evolving schema without first flattening current operational data into a second model.
RushDB operational analytics runs relationship-aware and schema-aware queries on the same current context used by applications and agents; it complements rather than replaces a mature analytical warehouse.
A chart can show change without preserving the context that explains it.
When events, entities, incidents, and application state are copied into separate analytical models, a metric and its operational cause drift apart. Teams rebuild the relationship during every investigation.
With RushDB
- Metrics calculated on current operational records
- Drill-downs connected to entities and incidents
- Property values and distributions inspectable directly
- Live schema available for change and missingness analysis
- One query model for applications, agents, and analytical views
Implementation walkthroughs
Run the workflow against your own records.
The requests are concrete and copyable. Result values are intentionally not simulated: inspect the records, metrics, generated queries, warnings, and scores returned by your configured project.
KPI
Calculate several full-scan metrics in one query.
Pure metrics use select keys for self-grouping and order by a selected metric so aggregation happens before pagination.
Request
const kpis = await db.records.find({
labels: ['EVENT'],
where: { featureId: 'checkout', type: 'conversion' },
select: {
conversions: { $count: '*' },
revenue: { $sum: '$record.value' },
avgOrder: { $avg: '$record.value', $precision: 2 },
},
groupBy: ['conversions', 'revenue', 'avgOrder'],
orderBy: { conversions: 'asc' },
})What to notice
- No root limit is applied before the aggregate.
- Inspect the selected conversions, revenue, and avgOrder fields; their values depend on your records.
Breakdown
Group the same records by a typed dimension.
Dimensional groupBy uses the record-field reference and returns that field name beside each metric row.
Request
const byChannel = await db.records.find({
labels: ['EVENT'],
where: { featureId: 'checkout', type: 'conversion' },
select: {
conversions: { $count: '*' },
revenue: { $sum: '$record.value' },
},
groupBy: ['$record.channel'],
orderBy: { conversions: 'desc' },
})What to notice
- The dimension is `$record.channel`; inspect the returned group key and selected metrics.
- A top-N limit should only be added when the product explicitly asks for top N.
Time series
Bucket conversion events by day.
The selected time-bucket key is also the group key and ordering key, producing a response ready for a chart.
Request
const daily = await db.records.find({
labels: ['EVENT'],
where: { featureId: 'checkout', type: 'conversion' },
select: {
day: { $timeBucket: { field: '$record.timestamp', unit: 'day' } },
conversions: { $count: '*' },
},
groupBy: ['day'],
orderBy: { day: 'asc' },
})What to notice
- The bucket is computed server-side from the typed datetime field.
- Inspect the returned day and conversions fields; bucket presence and values depend on matching records.
Evidence drill-down
Retrieve connected incidents as a separate evidence query.
A dashboard can follow a metric interaction with a relationship-aware record query. Keeping the responses separate avoids implying that an aggregate proved causality.
Request
const evidence = await db.records.find({
labels: ['INCIDENT'],
where: {
status: 'open',
FEATURE: { featureId: 'checkout' },
},
orderBy: { openedAt: 'desc' },
limit: 20,
})What to notice
- Any returned records are relevant evidence connected to the feature, not automatic causal attribution.
- The browser should call a server-owned drill-down endpoint with approved filters and limits.
Shared primitives
Explain operational data without disconnecting it.
These capabilities operate on the same records, relationships, schema, values, and semantic representations used elsewhere in the platform.
01
Counts and aggregations
Calculate operational metrics with select, grouping, and time-aware query shapes.
02
Relationship patterns
Inspect how entities, events, incidents, and outcomes connect.
03
Value distributions
Explore actual property domains, ranges, and missing values.
04
Schema change
Inspect the live shape of evolving records and identify newly introduced fields.
05
Entity timelines
Keep customer, process, or investigation history connected to current state.
06
Grounded analytical agents
Let software inspect available labels, fields, values, and paths before generating a query.
Example systems
Operational questions that benefit from connected context.
Customer and process timelines
Connect interactions, events, subscriptions, incidents, and outcomes around one entity.
Evidence investigations
Move from a metric or alert to the records and relationship paths that explain it.
Schema and data quality
Inspect value domains, missingness, and evolving fields while the data remains in use.
Operational analytics, not a universal warehouse replacement.
Use RushDB when current records, relationship paths, live schema, and application-facing queries belong in the same operational loop. Keep Snowflake, BigQuery, ClickHouse, or another warehouse for large-scale historical processing, specialized columnar workloads, or established enterprise BI models.