Streaming reads
STREAM SELECT follows results live; STREAM HISTORICAL replays from history then follows the live tail.
A streaming read is a query that does not terminate: it delivers the current result, then keeps emitting changes as new data arrives. This is the read side of NYXDB's streaming model.
STREAM SELECT
STREAM SELECT opens a live subscription over a relation. The client receives an
initial snapshot, then positional change operations (insert / update / remove) as
rows change.
STREAM SELECT market, amount FROM trades WHERE amount > 1000;Aggregates work too — the result is maintained incrementally:
STREAM SELECT count() FROM trades;
STREAM SELECT sum(amount) FROM trades;The engine's tests use the STREAM SELECT … spelling. The nyxsql CLI also
accepts SELECT STREAM … for follow-live reads. Both open a subscription; use
whichever your client documents.
STREAM HISTORICAL
STREAM HISTORICAL replays a relation from history and then follows the live
tail with no handoff seam — the same storage contract serves the backfill and
the follow.
STREAM HISTORICAL SELECT price FROM px;This is the primitive behind "start from the beginning, then stay current"
subscribers. It composes with EXPLAIN:
EXPLAIN STREAM HISTORICAL SELECT price FROM px;One-shot HISTORICAL
Without STREAM, HISTORICAL SELECT is a one-shot read over history (no live
follow):
HISTORICAL SELECT * FROM plain;
HISTORICAL SELECT ts, price FROM ex ORDER BY ts;How freshness is delivered
Streaming reads stay current through PSI, the engine's
routing layer: committed changes are delivered only to the subscribers whose
stream:key and predicate match, rather than by polling storage. Delivery health
(pending events, lag percentiles) is observable in
system.subscriptions.