DB
Concepts

Streaming reads

Open an Experimental live query, receive its initial snapshot, and apply subsequent result changes.

Streaming reads are Experimental. They are functional and tested in the single-node profile, but protocol compatibility, reconnect behavior, and distributed continuity are not stable production contracts.

Live read

STREAM is a statement prefix:

STREAM SELECT market, amount
FROM trades
WHERE amount > 1000
ORDER BY market;

Streaming is always a statement prefix: STREAM SELECT. A successful subscription delivers an initial result and then result changes until the client cancels, disconnects, the source is dropped, or execution fails.

Aggregates can be maintained incrementally when their functions satisfy the streaming state contract:

STREAM SELECT market, count() AS trades, sum(amount) AS volume
FROM trades
GROUP BY market
EMIT CHANGELOG ON UPDATE;

Historical replay then follow

Historical replay is an attribute-table surface in v1. The projection may contain one declared attribute plus the table's entity and axis columns. The example table is defined in the SELECT reference:

STREAM HISTORICAL
SELECT instrument_id, observed_at, price
FROM instrument_prices;

HISTORICAL SELECT without STREAM is a terminating historical read:

HISTORICAL SELECT instrument_id, observed_at, price
FROM instrument_prices;

STREAM HISTORICAL rejects ORDER BY, DISTINCT, LIMIT, and projections that span multiple independent attributes. Historical replay and live follow share one local storage frontier so the handoff does not omit or duplicate a committed row. Client reconnect remains the client's responsibility.

Result deltas

Materialized streams start with a snapshot and then publish positional insert/replace/update/remove/move operations. Drivers maintain a client-side replica by applying those operations in order. A changelog view may expose the operations directly instead of reconciling them into a grid.

Windows and emit policy

Streaming queries support tumbling, hopping, and session windows with explicit emit behavior:

STREAM SELECT window_start, count() AS events
FROM tumble(events, ts, INTERVAL 1 minute)
GROUP BY window_start
EMIT AFTER WINDOW CLOSE;

See Streaming SQL for EMIT PERIODIC, EMIT CHANGELOG, session gaps, and validation rules.

Operations

Use system.subscriptions for per-transport PSI backlog, bytes, overflow, and delivery-lag percentiles. system.queries shows the shared live query and subscriber count.

Cancel at the client, close the stream transport, or issue:

CANCEL QUERY 42;

If a transport closes unexpectedly, discard any assumption of uninterrupted delivery and establish a new snapshot.

On this page