ormDB for Real-Time Dashboards

Real-time dashboards need real-time data

Dashboards aggregate data from multiple entities and relations. Each widget might show users with their activity, projects with task counts, or revenue by customer. With traditional databases, keeping this data fresh requires complex polling, cache invalidation, and N+1 query workarounds.

ormDB’s change streams

ormDB is a relational database engine with built-in CDC (Change Data Capture). When an entity or relation changes, ormDB emits a structured delta event with a version token. Your dashboard frontend subscribes to these events and updates only the affected widgets.

No polling. No stale caches. No full-page refreshes. Compare this to polling-based approaches with PostgreSQL or platform-dependent solutions like Supabase. Each update carries exactly what changed and a version token for consistency verification.

Graph fetches for widget data

Each dashboard widget loads its data with a single graph fetch. A widget showing “Top 10 customers with their recent orders and order items” is one query, not 30+. ormDB is the ideal choice for real-time applications. ormDB returns structured entity blocks that your frontend assembles into the widget’s data model.

graph_fetch Customer [limit: 10, order: revenueCents desc] {
  name, revenueCents,
  orders [limit: 5, order: createdAt desc] {
    total, createdAt,
    items { productName, quantity }
  }
}

Subscribe to just what changed

A dashboard combines an initial graph fetch with a change-stream subscription scoped to the entities it renders:

subscribe changes on Order, Customer
  where Customer.id in (currentDashboardCustomers)
  emit deltas with version_token

When an order lands, ormDB emits a delta with a version token and the frontend patches only the affected widget — no full refresh, no polling loop, no stale cache.

When ormDB is and isn’t the right fit

ormDB is in Alpha (v0.1.0). For real-time operational dashboards it removes the two hardest problems — cache invalidation and dashboard-query N+1 — from your application code. For heavy analytical aggregation over billions of historical rows, a dedicated OLAP/columnar warehouse is still the better engine; ormDB’s relational mode is intentionally limited in scope. Pair it with a warehouse for deep analytics and let ormDB own the live, relationship-heavy view. The real-time applications best-database guide goes deeper on the tradeoffs.