Realtime Subscriptions
The Rust SDK supports live queries over a shared WebSocket connection.
Ownership boundary:
link-commonowns the shared connection, reconnect loop, replay filtering, andSeqIdcheckpoint tracking.- Your app owns the async loop over
live.next()orevents.next().
Live SQL must follow the strict supported shape: SELECT ... FROM ... WHERE ....
Do not include ORDER BY or LIMIT in live subscription SQL. Apply ordering or row caps in application code after rows arrive, or use LiveRowsConfig::limit.
Call client.connect().await? before opening subscriptions so they multiplex over one socket (unless you rely on lazy connect on first subscription).
Which API to use
| API | Use when |
|---|---|
live() / live_with_config() | You want the current materialized row list (recommended for UI and most services) |
live_events() / live_events_with_config() | You need raw ChangeEvent frames for custom reconciliation or debugging |
Unlike execute_query, live APIs take the final SQL string directly — there is no separate params argument. Embed constants in the WHERE clause or use separate subscriptions per filter.
Materialized live rows
Shorthand when defaults are enough:
Control knobs
| Knob | Layer | Effect |
|---|---|---|
with_batch_size(n) | Server snapshot | Chunks initial rows from the server |
with_last_rows(n) | Server rewind | How much history to fetch on connect |
LiveRowsConfig { limit: Some(n), .. } | Client materializer | Caps rows kept in memory after reconciliation |
with_from(seq_id) | Resume | Continue from a persisted SeqId |
Each LiveRowsEvent::Rows includes last_seq_id for durable checkpoints.
Low-level change events
Inspect active subscriptions
Cancel one explicitly:
Topic consumers (optional)
Topic workers are behind the consumer feature — not a separate crate.
Full walkthrough: Topic Consumer example.