What are Real-Time Live Queries?

A live query is a subscription to a database query — the server pushes create, update, and delete events for matching rows as they happen. It’s the missing tense of database access: normal queries speak in the past (“what matched when I asked”), live queries speak in the continuous present (“what matches, as it changes”). The screen stops asking and starts staying right.

Key takeaways

The subscription, in code

The defining move — take the query you already had, and subscribe to it:

// JavaScript / Node.js — Back4app JS SDK
// A live query: subscribe to a QUERY and receive its changes as events
const query = new Parse.Query('Task');
query.equalTo('assignee', currentUser);

const sub = await query.subscribe();
sub.on('create', (t) => addRow(t));       // new match appeared
sub.on('update', (t) => refreshRow(t));   // a match changed
sub.on('enter',  (t) => addRow(t));       // edited INTO the result set
sub.on('leave',  (t) => removeRow(t));    // edited OUT of the result set
sub.on('delete', (t) => removeRow(t));    // a match was deleted

// Flutter / Dart — Back4app Flutter SDK
// A live query: subscribe to a QUERY and receive its changes as events
final liveQuery = LiveQuery();
final query = QueryBuilder<ParseObject>(ParseObject('Task'))
  ..whereEqualTo('assignee', currentUser);

final sub = await liveQuery.client.subscribe(query);
sub.on(LiveQueryEvent.create, (t) => addRow(t));     // new match
sub.on(LiveQueryEvent.update, (t) => refreshRow(t)); // match changed
sub.on(LiveQueryEvent.enter, (t) => addRow(t));      // edited into the set
sub.on(LiveQueryEvent.leave, (t) => removeRow(t));   // edited out of the set

// iOS / Swift — Back4app Swift SDK
// A live query: subscribe to a QUERY and receive its changes as events
let query = Task.query("assignee" == currentUser)

let subscription = query.subscribeCallback
subscription?.handleEvent { _, event in
  switch event {
  case .created(let t):  addRow(t)        // new match appeared
  case .updated(let t):  refreshRow(t)    // a match changed
  case .entered(let t):  addRow(t)        // edited INTO the result set
  case .left(let t):     removeRow(t)     // edited OUT of the result set
  case .deleted(let t):  removeRow(t)
  }
}

// Android / Kotlin — Back4app Android SDK
// A live query: subscribe to a QUERY and receive its changes as events
val client = ParseLiveQueryClient.Factory.getClient()
val query = ParseQuery.getQuery<ParseObject>("Task")
query.whereEqualTo("assignee", currentUser)

val sub = client.subscribe(query)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, t -> addRow(t) }
sub.handleEvent(SubscriptionHandling.Event.UPDATE) { _, t -> refreshRow(t) }
sub.handleEvent(SubscriptionHandling.Event.ENTER)  { _, t -> addRow(t) }
sub.handleEvent(SubscriptionHandling.Event.LEAVE)  { _, t -> removeRow(t) }

The event vocabulary deserves its table, because enter and leave are what make this query subscription rather than table notification:

The pipeline behind the push

Two halves, cleanly separable: the change source — the database’s own write feed (change streams in document stores, replication logs elsewhere) — and the matching layer, which checks each change against every registered predicate and pushes to exactly the subscribers whose results changed, permissions enforced per subscriber. The open LiveQuery protocol is a readable reference implementation of the whole shape.

Live queries vs. polling vs. SSE vs. WebSockets

The last column is the argument: with raw sockets you build the message protocol, the routing, the permission checks, and reconnect-catch-up; with live queries the predicate is the protocol and the platform owns the rest.

Common use cases

• Chat and inboxes — subscribe to the conversation’s messages; arrival is an event, not a refresh.
• Live dashboards — orders, metrics, fleets: the query defines the view, events keep it true.
• Collaborative apps — shared task boards and documents where five people’s edits interleave in seconds.
• Presence and status — who’s online, what’s in progress — enter/leave doing their precise work.
• Operational screens — support consoles and admin views that must reflect production now, not at last refresh.

Poll, push, or subscribe? A decision matrix

The client-side discipline that keeps subscriptions healthy, whatever you choose: subscribe narrowly (selective predicates on indexed fields), and unsubscribe when the screen closes — standing queries are server state, and screens that leak them accumulate cost invisibly.

Limitations and trade-offs

• Matching is a real workload. Every write is checked against registered predicates; thousands of broad subscriptions on hot classes multiply it — selectivity is the lever.
• Connections are state. The socket fleet needs affinity, heartbeats, and fan-out backplanes — managed platforms exist precisely because this is undifferentiated heavy lifting.
• Reconnects need catch-up. A client that was offline missed events; robust flows re-run the base query on resubscribe rather than trusting the gap was quiet.
• Ordering and delivery are at-least-once shaped. Idempotent event handlers (apply by object ID, not by append) absorb the occasional duplicate gracefully.
• Not everything wants a subscription. Rarely-viewed, rarely-changed data is polling territory; live queries earn their cost where eyes and writes are both frequent.

Live queries on Back4app

Back4app is an open-source Backend-as-a-Service (BaaS) platform that combines a managed database, auto-generated REST and GraphQL APIs, authentication, file storage, and Cloud Code serverless functions. Live Query is its real-time layer, and the code tabs above are the entire client story: the same query builder you already use, one subscribe call, five typed events — with ACLs checked per subscriber so real-time never bypasses the permission model, and the WebSocket fleet, change streams, and fan-out running as managed infrastructure. Enable Live Query on a class in the dashboard, subscribe from any SDK, and the continuous present tense is a feature, not a project.