Push Notifications vs. Live Query Subscriptions: which do you need?

A push notification is an OS-delivered alert that reaches closed apps; a live query streams data changes while the app is open. Framing them as rivals is the classic mistake — they cover disjoint app states, and the real design question is not “which one” but “where is the user right now?” Most apps that feel properly real-time run both and route by that answer.

Key takeaways

Both channels, in code

The pattern nearly every messaging, ordering, and alerting app converges on:

// JavaScript — Back4app JS SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
const messages = new Parse.Query('Message');
messages.equalTo('conversation', conversationId);
const sub = await messages.subscribe();
sub.on('create', (m) => appendBubble(m));   // full object, real time

// While it is CLOSED — push owns delivery: register this device
const installation = await Parse.Installation.currentInstallation();
installation.set('channels', [`user-${currentUser.id}`]);
await installation.save();
// A Cloud Code afterSave trigger sends the push to this channel —
// the OS shows the alert; the tap opens the app, which re-subscribes.

// Flutter / Dart — Back4app Flutter SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
final liveQuery = LiveQuery();
final messages = QueryBuilder<ParseObject>(ParseObject('Message'))
  ..whereEqualTo('conversation', conversationId);

final sub = await liveQuery.client.subscribe(messages);
sub.on(LiveQueryEvent.create, (m) => appendBubble(m)); // full object

// While it is CLOSED — push owns delivery: register this device
final installation = await ParseInstallation.currentInstallation();
installation.set('channels', ['user-$userId']);
await installation.save();
// A Cloud Code afterSave trigger sends the push to this channel —
// the OS shows the alert; the tap opens the app, which re-subscribes.

// iOS / Swift — Back4app Swift SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
let messages = Message.query("conversation" == conversationId)
let subscription = messages.subscribeCallback
subscription?.handleEvent { _, event in
  if case .created(let m) = event { appendBubble(m) }  // full object
}

// While it is CLOSED — push owns delivery: register this device
var installation = Installation.current
installation?.channels = ["user-\(userId)"]
installation?.save { _ in }
// A Cloud Code afterSave trigger sends the push to this channel —
// the OS shows the alert; the tap opens the app, which re-subscribes.

// Android / Kotlin — Back4app Android SDK: one channel per app state
// While the app is OPEN — the live query delivers the data itself
val client = ParseLiveQueryClient.Factory.getClient()
val messages = ParseQuery.getQuery<ParseObject>("Message")
messages.whereEqualTo("conversation", conversationId)

val sub = client.subscribe(messages)
sub.handleEvent(SubscriptionHandling.Event.CREATE) { _, m ->
    appendBubble(m)                                  // full object
}

// While it is CLOSED — push owns delivery: register this device
val installation = ParseInstallation.getCurrentInstallation()
installation.put("channels", listOf("user-$userId"))
installation.saveInBackground()
// A Cloud Code afterSave trigger sends the push to this channel.

Note what each half handles: the subscription delivers data — whole objects, typed events, in real time. The installation registers for attention — the right to interrupt the user later, through a pipeline your app does not control.

Two deliveries, two owners

The paths could hardly be more different, and every property in the comparison table falls out of who owns the last mile.

A push notification leaves your backend as a request to an OS-operated gateway — the iOS and Android push gateways (APNs, FCM), or a browser push service speaking RFC 8030 on the web. The gateway owns delivery: it holds messages for offline devices, coalesces and throttles under battery pressure, and wakes your app or renders the banner. That borrowed power is the whole point — only the OS can reach a process that isn’t running — and the whole constraint: payloads capped around 4 KB, delivery best-effort, silent background wakeups rationed per day, and the payload outside your backend’s permission model.

A live query never leaves your trust boundary: the app holds a WebSocket to the backend’s subscription server, which matches every database write against the subscribed query and pushes typed events — create, update, enter, leave, delete — with ACLs enforced per subscriber. Full objects, real-time latency, no payload ceiling worth naming. The dependency is brutal in exchange: the subscription is state inside your process, and when the OS suspends the app — which mobile platforms do aggressively — the socket, and the channel, are gone.

Push notifications vs. live queries

The rows compose cleanly because the two channels answer different questions: push answers “how do I reach the user?”, live queries answer “how does the screen stay true?” — which is why the transport-level comparison of SSE, WebSockets, and polling lives entirely inside the second question.

The handoff: where apps actually break

The bugs live at the seam between channels. A user taps a push about a message that was also delivered by live query before the app suspended — deduplicate by object ID, not by channel. A push arrives about data the user can no longer access — fetch through the normal API on open and let the ACLs answer, never trust the payload. The app was closed for three days — the reopened app cannot replay a gap from push (notifications are not a journal), so the handoff is always re-subscribe, then re-run the base query to rebuild truth, with the push token registration kept fresh in the background. Design the seam once and both channels become boring — which is the goal.

Common use cases

• Chat and messaging — live query renders the open conversation; push carries “new message” through the closed state. The canonical both-channels app.
• Order and delivery tracking — the open tracking screen subscribes; status flips to “delivered” while closed arrive as push.
• Operational alerting — on-call consoles subscribe for the wallboard; the pager path is push, because nobody keeps the app open at 3 a.m.
• Auctions and drops — live price movement in-app; outbid-while-away is a push, deep-linking back into the live screen.
• Social engagement — likes and replies land as push re-engagement; the opened feed goes live via subscription.

Which channel should you use? A decision matrix

Limitations and trade-offs

• Push is not a data channel. Payload caps, opaque routing outside your ACLs, and coalescing make it structurally wrong for carrying state — send pointers, fetch truth on open.
• Push delivery is a probability, not a promise. Battery optimizers, revoked permissions, and gateway throttling all drop messages silently; anything that must not be missed needs a query-based reconciliation path.
• Live queries stop at the process boundary. No socket survives suspension; treating a subscription as an always-on channel is the false assumption behind most “we missed events” bugs.
• Both channels tax the client. Over-broad subscriptions burn battery and server matching; over-eager push burns goodwill — the uninstall is the user’s rate limiter.
• The seam is your responsibility. Deduplication, catch-up queries, and token refresh are application logic; neither channel provides them for free.

Push and 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. Both channels ship built in and share one write path: a Cloud Code afterSave trigger on the same database write can send the push — through the platform’s gateway integrations with device and channel targeting — while Live Query fans the full object out to every subscribed, permission-checked client automatically. The routing diagram above collapses to one trigger and one subscribe call, and the seam logic — catch-up queries, token registration via the Installation class — runs through the same SDKs shown in the code tabs.