Transforms
Continuous, in-database pipelines defined with CREATE TRANSFORM ... INTO ... and kept fresh through PSI routing.
A transform is a standing pipeline that runs inside the database. You define it
once with CREATE TRANSFORM, and NYXDB keeps its target fresh as new data
arrives — no external stream processor.
Defining a transform
A transform reads from a source and writes into a target table. Its body must project the target's primary key column(s).
CREATE TRANSFORM t_a INTO k AS SELECT id, v FROM src;Transforms compose — one transform's target can be another's source:
CREATE TRANSFORM t_b INTO k2 AS SELECT id, v AS v2 FROM k;A CREATE TRANSFORM requires an AS SELECT body and an INTO <target>; the
target must exist and the body must project its primary key. Aggregating and
windowed transform bodies are supported by the engine; the exact windowing
function spellings are covered in the function reference
and marked TODO-verify where not yet confirmed.
How freshness works
Transforms stay current through PSI: committed changes are routed only to the subscribers that need them, so the target updates incrementally instead of by re-scanning the source on a timer. Recovery is gap-free — a transform resumes from its reflected position rather than reprocessing from the beginning.
Managing transforms
Transforms are catalog objects. They can be shown, paused, resumed, and dropped.
SHOW TRANSFORMS;
ALTER TRANSFORM t_a PAUSE;
ALTER TRANSFORM t_a RESUME;
DROP TRANSFORM t_a;A paused transform survives restart and replay: its paused state is durable, and resuming catches up from where it stopped.
Observing transforms
The system.transforms table shows each
transform's source, target, state, reflected position, lag, rows emitted, and
last error — rebuilt every refresh from the catalog and runtime.