DB
Get started
Back homeIndustry

Media & streaming

Playback QoE telemetry, live engagement counters and session state on one engine, with durable ingest and keyed current state.

The problem

Where the usual stack breaks

  1. 01

    A streaming platform watches a very large number of concurrent sessions: playback telemetry such as rebuffering, bitrate and startup time streams in continuously, engagement counters move every second, and the questions that matter are about the live audience right now.

  2. 02

    The typical stack splits QoE telemetry into a stream processor, live counters into a cache and session history into a warehouse: three systems that drift, and a viewer-experience dashboard that lags the incident it is meant to catch.

  3. 03

    You want one engine that stores QoE events durably, maintains per-session and per-title state, and rolls up live engagement in the same SQL.

Where NYXDB fits

Use-case journeys

01

QoE observability

Raw playback telemetry becomes live per-title QoE metrics, maintained by materialized views.

Observability & logs
02

Live engagement dashboards

Dashboards read maintained relations and subscribe to live counters.

Real-time dashboards
03

Playback time series

Columnar QoE history and windowed aggregates for trend analysis.

Time-series & monitoring

Architecture

How NYXDB fits streaming telemetry

Playback events land in one durable table; keyed tables hold the latest state per session and title; grouped STREAM SELECT and transformations maintain the engagement figures your dashboards read and follow.

  1. 01

    Ingest

    Every playback event is durable before it is acknowledged.

  2. 02

    Session state

    The latest row per (session, title), in an UPSERT table.

  3. 03

    Engagement rollups

    Totals per title stay current, maintained by grouped transformations; windows run in STREAM SELECT.

  4. 04

    Live streams

    QoE and engagement changes reach dashboards as they commit, with STREAM SELECT.

In practice

Representative query

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

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;

Capabilities

What you get out of the box

Durable ingest

Writes persisted before acknowledgement.

Keyed session state

Latest row per session and title.

Windowed engagement

Tumbling and hopping windows in STREAM SELECT.

Live push

Changes reach QoE dashboards as they commit, with STREAM SELECT.

Learn more

Go deeper

Tables

Current state per session.

Transformations

Continuous rollups.

Streaming reads

Snapshot then incremental changes.

Telemetry your streaming ops can query

Explore observability or run a node.

Get startedRead the docs