Skip to main content
DB
Back homeUse case

Feature stores & ML features

Serve the latest features per entity in one read, and train on exactly the values that were true at the time, from the same tables.

The problem

Where the usual stack breaks

  1. 01

    Feature pipelines usually run twice: once as a batch job for training and once as a streaming job for serving. The two drift apart, and the model learns from values the serving path never produced.

  2. 02

    Point-in-time correctness is the hard part. A training row must see the features as they stood when the label happened, not what a later backfill overwrote, and rebuilding that from logs is slow and fragile.

  3. 03

    The fit is one engine that maintains per-entity features from the event stream, serves the latest row per key, and can read any table exactly as it was at a past commit.

Architecture

How NYXDB fits feature serving

Events append; transformations fold them into per-entity feature tables kept current from every committed write; the latest row per key is served from the same engine, and AS OF COMMIT reads give training the exact past state.

  1. 01

    Ingest

    Raw events append through SQL, write batches or native bulk frames.

  2. 02

    Derive

    Grouped transformations maintain counts, sums and last-seen values per entity in a keyed table.

  3. 03

    Serve

    A keyed read returns the latest features per entity, and a committed write is visible to the next statement.

  4. 04

    Train

    SELECT … AS OF COMMIT returns the features as they stood at a past commit, for point-in-time training sets.

Examples

In practice

Per-entity activity features, maintained from every transfer
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;
The features as they stood at a past commit
SELECT address, token, transfer_count, last_transfer_at
FROM balances AS OF COMMIT 42
WHERE chain_id = 1;

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

Maintained features

Per-entity counts, sums and last-seen values kept current by transformations.

One row per entity

The latest features per key, served from the same table the pipeline writes.

Point-in-time reads

Training sets read the exact past state, with AS OF COMMIT.

Live feature streams

Feature changes pushed to online consumers as they commit, with STREAM SELECT.

Learn more

Train and serve from the same truth

Run a node and maintain your first feature table.