SurrealDB WebSocket LIVE SELECT subscriptions versus HTTP REST live-change delivery

Direct Answer

WebSocket LIVE SELECT with WHERE clauses is the supported path for server-side filtered live notifications. The WHERE clause is evaluated as part of the live query, so the server can suppress rows that never match or stop matching. HTTP REST does not reliably expose the same filtered streaming subscription in any documented build; it remains primarily request/response. Delivery guarantees (ordering, exactly-once, resume-after-reconnect) are version-specific and not uniformly guaranteed across self-hosted, Cloud, or version lines.

Confirmed Facts

• WebSocket is the documented persistent transport for LIVE SELECT subscriptions.
• A LIVE SELECT ... WHERE ... query maintains a server-side result set; CREATE/UPDATE/DELETE events translate into add/update/remove notifications for matching rows.
• When an updated row stops matching the WHERE clause, the server emits a removal/delete-style notification (exact payload shape varies by version).
• HTTP REST endpoints for SQL, key operations, and metadata are request/response. Any HTTP-based live/changes stream is build-specific and undocumented as a stable API.
• No built-in alerting engine exists: deduplication, debounce, quiet hours, thresholds, and routing must be implemented in the consumer or an external notifier.

Likely Explanations (Version-Sensitive)

• Permission re-evaluation: Whether table SELECT permissions and session/auth context are re-checked per notification or only at subscription time depends on the server version. Test by changing a session variable that affects a permission after subscribing.
• Ordering: Notifications are ordered per live query/connection, not as a global transactional guarantee.
• Exactly-once: Not advertised. Expect at-least-once or at-most-once depending on version and network conditions.
• Reconnect behavior: After WebSocket disconnect, missed changes are generally not replayed unless the specific build exposes a durable/versioned change feed with retention. Plan to re-run LIVE SELECT and reconcile state on reconnect.
• DIFF/CHANGES syntax: Names and options for differential payloads vary by version; verify in your build's documentation.

Verification Steps for Your Build

1. Open a WebSocket connection and run LIVE SELECT * FROM table WHERE condition.
2. Perform CREATE, UPDATE (matching → non-matching), and DELETE operations; record the exact action types and payloads received.
3. Attempt the same subscription via the HTTP API in your target build; check whether a persistent stream exists and whether WHERE/DIFF options are honored.
4. Kill the WebSocket, make changes while offline, then reconnect; observe whether events are missed, duplicated, or reordered.
5. Create a table permission that depends on a session variable, subscribe, change the variable, then mutate a row; verify whether notifications stop or continue.

One Missing Diagnostic Detail

Exact SurrealDB version and deployment (self-hosted version tag, Cloud tier, or custom build). This determines which of the above behaviors apply and whether any HTTP live endpoint exists.