The Problem with Traditional Dashboards
Most real-time dashboards use one of these approaches:
- Polling: Query every 5 seconds. Wasteful, laggy, and database-intensive.
- WebSocket + Cache: Complex cache invalidation logic. Race conditions galore.
- Change Streams: Only work for simple queries. Aggregations require re-querying.
The Cosmictron Difference
Subscribe to any SQL query—including complex aggregations with JOINs—and receive incremental deltas automatically. When one row changes, only affected aggregations recalculate. Dashboard updates in milliseconds, not seconds.
Example: E-commerce Analytics
Real-time Metrics
-- Revenue by hour (auto-updating) SELECT DATE_TRUNC('hour', created_at) AS hour, SUM(total) AS revenue, COUNT(*) AS orders, AVG(total) AS avg_order_value FROM orders WHERE created_at > NOW() - INTERVAL '24 hours' GROUP BY hour ORDER BY hour DESC; -- Top products (live leaderboard) SELECT p.name, p.image_url, SUM(oi.quantity) AS units_sold, SUM(oi.quantity * oi.price) AS total_revenue FROM products p JOIN order_items oi ON p.id = oi.product_id GROUP BY p.id ORDER BY units_sold DESC LIMIT 10;
Client Subscription
// Subscribe to hourly revenue chart const revenueSub = await client.subscribe( `SELECT DATE_TRUNC('hour', created_at) AS hour, SUM(total) AS revenue, COUNT(*) AS orders FROM orders WHERE created_at > NOW() - INTERVAL '24 hours' GROUP BY hour ORDER BY hour DESC`, (delta) => { // Update chart with new data delta.inserts.forEach(row => chart.addDataPoint(row)); delta.updates.forEach(row => chart.updateDataPoint(row.hour, row)); } ); // Live updating KPI cards const kpiSub = await client.subscribe( `SELECT COUNT(*) FILTER (WHERE created_at > NOW() - INTERVAL '1 hour') as orders_last_hour, SUM(total) FILTER (WHERE status = 'pending') as pending_revenue, AVG(total) as avg_order_value FROM orders`, (delta) => { updateKPIs(delta.inserts[0]); } );
DBSP: How It Works
Cosmictron uses DBSP (Database Stream Processing), a research breakthrough from the 2023 VLDB conference:
🔬 Research-Backed
Based on "DBSP: Automatic Incremental View Maintenance" by Budiu et al. Proven correctness.
⚡ Incremental Everything
Not just filters—joins, aggregations, and nested queries all update incrementally.
📉 O(delta) Complexity
Work proportional to changed data, not total data. 10-100x faster at scale.
🔒 ACID Guarantees
All updates happen within ACID transactions. No dirty reads or race conditions.
Traditional databases re-run entire queries when data changes. With 1M rows and a query touching 100K of them, that's 100K operations per update. DBSP tracks which rows affect which query results, so only changed values are recalculated.
Performance Comparison
Scenario: Dashboard with 10 charts showing real-time aggregations from 1M orders table.
| Approach | Latency | CPU per Update |
|---|---|---|
| Polling (5s) | 2-5 seconds | 10 full table scans/minute |
| Materialized Views | Minutes (batched) | 10M+ rows/minute |
| Cosmictron DBSP | < 1ms | Only changed rows |
Use Cases
- Financial Trading: Real-time P&L, position tracking, risk metrics
- IoT Monitoring: Sensor data aggregation, anomaly detection
- E-commerce: Live sales dashboards, inventory tracking
- DevOps: System metrics, error rates, latency percentiles
- Gaming: Leaderboards, match statistics, economy metrics