Back homeIndustry

Gaming

Leaderboards, live telemetry and player state on keyed tables, with reducers that keep the best score and streams that push every change.

The problem

Where the usual stack breaks

01
A game backend is delay-sensitive and correctness-sensitive at once: the leaderboard has to update promptly and rank correctly, player state is read on every action, and live telemetry arrives in bursts at peak. The usual answer is a cache for leaderboards and sessions, a database for durable state and a pipeline for telemetry: three systems on the hot path.
02
The split shows up as bugs your players notice: a rank that lags the score that produced it, a player read that misses the previous write, a live-ops dashboard well behind the match.
03
You want a durable store with keyed tables that combine writes the way the game means them, and live reads that push changes to clients.

Where NYXDB fits

Use-case journeys

Live leaderboards

Leaderboards kept current as scores land, followed live by clients.

Real-time dashboards

Session & player state

Player state and stats on one engine — operational writes and analytical scans without ETL.

HTAP & operational analytics

Match telemetry & live ops

Match events folded into live-ops metric tables.

Product & event analytics

Architecture

How NYXDB fits gaming

Scores live in keyed tables whose columns declare a reducer: REDUCER MAX keeps a player’s best result as writes arrive; match events land in an append-only table; STREAM SELECT pushes every leaderboard change to clients.

01
Player state
One row per player in an UPSERT table; a BLOOM index serves lookups by handle.
02
Leaderboard
The best score per player keeps itself, with REDUCER MAX on the score column.
03
Telemetry
Match events land in an append-only table for live and post-match analytics.
04
Live views
Leaderboard and match changes reach clients 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.

Balances, as a versioned table with a slice per producer

CREATE TABLE balances (
  chain_id UINT16 NOT NULL,
  address STRING NOT NULL,
  token STRING NOT NULL,
  amount UINT256 NULL,
  updated_at DATETIME64(3, 'UTC') NULL,
  balance_index UINT128 NULL,
  balance_version UINT64 NULL,
  transfer_count UINT64 NULL,
  last_transfer_at DATETIME64(3, 'UTC') NULL,
  activity_index UINT128 NULL,
  PRIMARY KEY (chain_id, address, token),
  ATTRIBUTE GROUP holding (amount, updated_at, balance_index, balance_version)
    VALID BY (balance_index)
    REVISION BY (balance_version),
  ATTRIBUTE GROUP activity (transfer_count, last_transfer_at, activity_index)
    VALID BY (activity_index)
)
MODE VERSIONED
SHARD BY (address) SHARDS AUTO
ORDER BY (chain_id, address, token);

Capabilities

What you get out of the box

Keyed tables

Leaderboards and player state in SQL.

Column reducers

Successive writes combine the way the game means them, with REDUCER MAX, MIN or SUM.

Maintained counts

Counts, sums, minimums and maximums, maintained by transformations.

Live push

Each change reaches clients as it commits, with STREAM SELECT.

Learn more

CREATE TABLE

Reducers and storage profiles.

Streaming reads

Push live changes.

Getting started

Run a node.

One engine for the game backend

Explore real-time dashboards or run a node.

Get startedRead the docs