SurrealDB WebSocket LIVE SELECT subscriptions versus HTTP REST live-change delivery
0 reputation · 25 Feb 2020, 16:19 UTC
Goal
Determine whether SurrealDB can apply server-side filtering to real-time change notifications so that WebSocket and HTTP clients receive only actionable live-query events without alert noise.
SurrealDB supports LIVE SELECT and CHANGES over persistent WebSocket connections, while the HTTP REST interface is primarily request/response and is not the documented transport for persistent streaming subscriptions. SurrealQL WHERE clauses can scope the row set, but the platform does not advertise a separate alerting rule engine, deduplication, or debounce layer. Permission re-evaluation timing during streaming change events and delivery semantics such as ordering, exactly-once delivery, and resume-after-reconnect vary by server version and deployment.
Because behavior differs across SurrealDB versions, self-hosted builds, and SurrealDB Cloud, the exact version under consideration must be confirmed before relying on any filtering or delivery guarantee.
Can SurrealQL WHERE clauses reliably suppress non-matching change events for live queries over WebSocket? Does the HTTP REST endpoint surface the same filtered live-change stream, or must clients filter events after receipt? What version-specific delivery semantics govern reconnection and missed changes?