DB
Back homeIndustry

Gaming

Leaderboards, live telemetry, and session state on in-memory keyed tables — microsecond reads, exact ranks, read-your-writes.

The problem

Why this is hard today

Game backends are latency-bound and correctness-sensitive at once: a leaderboard has to update instantly and rank exactly, session state is read on every action, and live telemetry arrives in a firehose during 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.

The split shows up as bugs players notice: a rank that lags the score that produced it, a session read that misses the write from the previous request, a live-ops dashboard minutes behind the match.

What a game backend needs is an in-memory store that is exact and speaks SQL, so leaderboards, sessions, and telemetry are tables — read in microseconds, written read-your-writes, ranked exactly.

Where NYXDB fits

Use-case journeys

Live leaderboards

Exact, instantly-updated ranks on in-memory keyed tables.

Caching & real-time serving

Session & player state

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

HTAP & operational analytics

Match telemetry & live ops

Line-rate event ingest continuously materialized into live-ops dashboards.

Real-time dashboards

Architecture

How NYXDB fits gaming

Scores and sessions live in in-memory keyed tables (read-your-writes, exact counts); telemetry appends at rate; live views push updates through PSI — one engine on the hot path.

  1. 01

    Session state

    A keyed, memory-resident table holds per-player session — O(1) reads and writes.

  2. 02

    Leaderboard

    Scores in a keyed table; exact ranks and counts from ordered reads.

  3. 03

    Telemetry

    Match events append at rate for live and post-match analytics.

  4. 04

    Live views

    STREAM SELECT pushes leaderboard and match updates to clients.

Real SQL

Representative query

Leaderboard on an in-memory keyed table
CREATE TABLE leaderboard (
  player_id UInt64 NOT NULL,
  score     Int64,
  PRIMARY KEY (player_id)
) SETTINGS mode='keyed', layout='row', storage_policy='memory_data';
SELECT player_id, score
FROM leaderboard
ORDER BY score DESC
LIMIT 100;

Every statement follows the engine’s own test SQL shapes. See the SQL reference for full syntax.

Capabilities

What you get

In-memory tables

Leaderboards and sessions in RAM, in SQL.

Microsecond reads

Keyed point reads on the hot path.

Exact ranks & counts

count() is O(1) and exact.

Read-your-writes

The score you wrote is the rank you read.

Proof

Measured on the vetted benchmark lane

71.6ns

point consult on warm postings

in-memory keyed read

vetted table

View benchmark230 ns

exact rank/count, O(1)

flat 1k–16k keys

vetted table

View benchmark12.45M rows/s

in-memory columnar append ceiling

narrow 4-column rows

vetted table

View benchmark

Measured on Apple M4 Max (dev), macOS — server-class validation pending. Release build, median of 5, commit-pinned (d4a3885b, 2026-07-07). Ingest figures are engine-side. See the full benchmark suite.

Learn more

Related documentation

Keyed tables

In-memory current state.

Streaming reads

Push live updates.

Getting started

Run a node in minutes.

One engine for the game backend

Explore caching & real-time serving or run a node.

Get started Read the docs