Back homeUse case

Product & event analytics

Ingest clickstream and product events, keep every product metric current with continuous SQL, and serve the numbers as ordinary reads that are followed live.

The problem

Where the usual stack breaks

01
Product analytics runs two clocks at once: a stream of clickstream and event data on the write side, and a wall of funnels, retention curves and live metric tiles on the read side, each recomputed by a warehouse on a schedule, so the numbers your team acts on are already old.
02
The usual stack bolts an event pipeline onto a stream processor, a warehouse for funnels and a cache for live tiles: three systems that disagree the moment an event lands, and a maintenance burden that grows with every new metric.
03
You want one engine that stores events durably, keeps metric tables current continuously, and serves the results as ordinary keyed reads.

Architecture

How NYXDB does it

Events land durably; grouped transformations and materialized views keep each metric relation current from every committed write; time windows run in STREAM SELECT; dashboards read the metric tables and follow them live.

01
Ingest events
Clickstream and product events land in an append-only table, durable before acknowledgement.
02
Roll up
Per-project, per-event counts and sums stay current in a keyed table, maintained by a grouped CREATE TRANSFORMATION.
03
Window
Time windows, TUMBLE, HOP or SESSION, run in STREAM SELECT; transformations fold without windows.
04
Serve metrics
Dashboards read the keyed metric tables; STREAM SELECT pushes each change.

Examples

In practice

Activity per balance, kept current by a transformation

CREATE TRANSFORMATION balance_activity INTO balances ATTRIBUTE GROUP activity AS
SELECT
  chain_id,
  recipient AS address,
  token,
  COUNT(*) AS transfer_count,
  MAX(transferred_at) AS last_transfer_at,
  MAX(_index) AS activity_index
FROM transfers
GROUP BY chain_id, recipient, token;

Live volume per token, as a query that stays open

STREAM SELECT chain_id, token, SUM(amount) AS volume, COUNT(*) AS transfers
FROM transfers
GROUP BY chain_id, token;

The examples use the same two tables on every page. See the SQL reference for full syntax.

Capabilities

What you get out of the box

Continuous rollups

Transformations and materialized views keep event metrics current.

PSI propagation

Each committed event reaches every subscriber that reads it.

Keyed serving

Metric tiles read keyed tables that folds keep current.

Maintained aggregates

Counts, sums, minimums, maximums, averages and distinct counts.

Windowed streams

Tumbling, hopping and session windows in STREAM SELECT.

Live push

Live metric tiles update without polling, with STREAM SELECT.

Learn more

Transformations

Continuous folds.

Streaming reads

Push changes to clients.

Getting started

Run a node.

Product metrics that are live, not batched

Fold an event table into metrics and stream them to the dashboard.

Get startedRead the docs