Using SurrealDB Live Queries to Skip a Separate Message Broker

The Pub/Sub Infrastructure Tax

When you need a live feed—such as a notification stream or a collaborative editor—you typically add a message broker (Redis, RabbitMQ, or Apache Kafka) and a WebSocket server to push database changes to clients. This adds operational overhead: you must write code to publish events after every insert/update, monitor the broker, and keep the broker and database in sync.

How SurrealDB Live Queries Replace the Broker

A Live Query is a persistent SurrealQL statement that the server evaluates continuously. By prefixing a SELECT with the LIVE keyword over a streaming connection (WebSocket or HTTP/2), the server maintains subscription state and pushes a record whenever a CREATE, UPDATE, or DELETE matches the query. The application only needs to handle the incoming JSON payload; no extra publish step is required.

Worked Example: Subscribing to Pending Orders

Assume a table order with fields status and total. To receive live updates for orders that are still pending, a client runs:

LIVE SELECT * FROM order WHERE status = 'pending';

When a new order is inserted with status 'pending', the server pushes the full record. If an existing pending order is updated to status 'shipped', the server pushes a deletion‑style event (the record no longer matches the filter). The client can distinguish event type by checking the method field in the SurrealDB response (CREATE, UPDATE, DELETE).

Trade‑offs and Operational Considerations

• Memory per subscription: Each active Live Query holds a cursor and connection state, consuming roughly a few kilobytes; thousands of concurrent subscriptions can affect heap usage.
• Connection scaling: Subscriptions are tied to the underlying TCP/WebSocket connection. Horizontal scaling of SurrealDB requires sticky sessions or an external coordinator to route a client back to the node that holds its subscription state.
• Replay on reconnect: Live Queries only stream changes that occur while the connection is alive. If a client disconnects, it must perform a regular SELECT to fetch current data before re‑issuing the LIVE query to avoid missing interim changes.
• Query complexity: Highly filtered or graph‑heavy LIVE queries force the engine to re‑evaluate the predicate for every write, which can increase CPU load during write spikes.

Verification Steps

1. Start a local SurrealDB instance (e.g., surreal start --log trace --user root --pass root memory).
2. Open two terminal sessions and connect each with the SurrealQL CLI: surreal sql --user root --pass root memory.
3. In the first session, run the Live Query: LIVE SELECT * FROM order WHERE status = 'pending';.
4. In the second session, insert a test record: CREATE order SET status = 'pending', total = 42;.
5. Observe that the first session receives a JSON payload containing the new order immediately.
6. To stop the stream, run UNLIVE in the first session.

These steps confirm that the database pushes changes without any external broker.

Actionable Closing

If your real‑time use case involves simple filters on a single table or modest graph traversals, SurrealDB Live Queries can eliminate the Redis/RabbitMQ layer and reduce operational surface. For high‑fan‑out scenarios or when you need guaranteed message replay, consider keeping a lightweight broker or building a client‑side catch‑up mechanism. Start with a local test, monitor memory usage per subscription, and adjust connection affinity as you scale.