---
term: 'Push-Benachrichtigungen vs. Live-Query-Abonnements'
seoTitle: 'Push-Benachrichtigungen vs. Live Queries: welcher Kanal?'
headline: 'Push-Benachrichtigungen vs. Live-Query-Abonnements: Was brauchen Sie?'
slug: push-vs-live-queries
category: api-realtime
shortDefinition: 'Eine Push-Benachrichtigung ist eine vom OS zugestellte Meldung, die geschlossene Apps erreicht; eine Live Query streamt Änderungen bei offener App.'
relatedTerms:
  - push-notifications-apns-fcm
  - real-time-live-queries
  - websockets-real-time-sync
  - sse-vs-websockets-vs-polling
contrastsWith:
  - real-time-live-queries
aboutTerms:
  - 'Push Notifications'
  - 'Live Query Subscriptions'
faq:
  - question: 'Was ist der Unterschied zwischen Push-Benachrichtigungen und Live Queries?'
    answer: 'Der Zustellweg und der App-Zustand, den sie bedienen. Eine Push-Benachrichtigung läuft über das Push-Gateway des Betriebssystems und erreicht das Gerät auch bei geschlossener App – trägt aber einen kleinen, undurchsichtigen Payload und gibt nur Best-Effort-Garantien. Eine Live Query ist ein WebSocket-Abonnement, das Ihre laufende App offen hält: vollständige Objekte, in Echtzeit, mit geprüften Berechtigungen – und tot in dem Moment, in dem die App es ist.'
  - question: 'Funktionieren Live Queries bei geschlossener App?'
    answer: 'Nein, und keine Findigkeit auf der Client-Seite ändert daran etwas. Eine Live Query ist Zustand innerhalb Ihres laufenden Prozesses – ein WebSocket, den die App offen hält. Suspendiert oder beendet das OS die App, stirbt der Socket mit ihr, und mobile Plattformen suspendieren Apps im Hintergrund aggressiv, um Akku zu sparen. Eine geschlossene App zu erreichen ist genau die Aufgabe, die sich das OS für sein eigenes Push-Gateway vorbehält.'
  - question: 'Sollte eine Chat-App Push-Benachrichtigungen oder Live Queries verwenden?'
    answer: 'Beides, aufgeteilt nach App-Zustand. Die geöffnete Unterhaltung abonniert eine Live Query – Nachrichten erscheinen sofort mit vollständigen Daten, samt Tippanzeige und Lesebestätigung. Die geschlossene App verlässt sich auf Push, um den Empfänger zu benachrichtigen, mit gerade genug Payload für das Banner. Der Tipp öffnet die App, die neu abonniert und die Basisabfrage erneut ausführt, um aufzuholen. Jeder verbreitete Messenger arbeitet so.'
  - question: 'Ist die Zustellung von Push-Benachrichtigungen garantiert?'
    answer: 'Nein – die Zustellung ist von der Konstruktion her Best Effort. Die Gateways des Betriebssystems fassen zusammen, drosseln und verwerfen Nachrichten unter Akkudruck, Nutzer entziehen Berechtigungen vollständig, und Geräte sind zeitweise nicht erreichbar. Stille Hintergrund-Pushes werden noch härter gedrosselt als sichtbare. Behandeln Sie Push als Tippen auf die Schulter, niemals als Vertrag über Datentransport; die App muss ihren Zustand nach dem Öffnen per Abfrage abgleichen.'
  - question: 'Wie groß darf der Payload einer Push-Benachrichtigung sein?'
    answer: 'Kilobyte, keine Daten. Die Gateways des Betriebssystems begrenzen Payloads auf rund 4 KB, und der Payload ist für das Berechtigungsmodell Ihres Backends undurchsichtig – was immer Sie hineinlegen, liegt außerhalb Ihrer ACLs in der Benachrichtigungs-Pipeline. Das robuste Muster sendet nur Kennungen und Anzeigetexte und lässt die geöffnete App die eigentlichen Objekte über die normale, berechtigungsgeprüfte API holen.'
  - question: 'Was ist eine stille Push-Benachrichtigung?'
    answer: 'Ein Push ohne sichtbare Meldung, der das OS bittet, Ihre App kurz im Hintergrund zu wecken – typischerweise, um Daten vorzuladen, damit das nächste Öffnen sofort wirkt. Es ist die am strengsten rationierte Ressource im Push-System: Das OS vergibt ein Weckbudget pro App und Tag und ignoriert den Überschuss. Stiller Push taugt daher als Optimierungsschicht, nie als verlässlicher Kanal für Synchronisierung.'
  - question: 'Brauche ich Push-Benachrichtigungen und Live Queries zugleich?'
    answer: 'Wenn Nutzern Ereignisse wichtig sind, die bei geschlossener App eintreten – Nachrichten, Bestellungen, Warnungen –, dann ja, fast unvermeidlich. Die beiden Kanäle decken disjunkte App-Zustände ab: Live Queries gehört die Erfahrung bei offener App, Push gehört die Rückgewinnung aus dem geschlossenen Zustand. Backends, die beides mitbringen, lassen einen einzigen Datenbankschreibvorgang in jeden Kanal fächern – beides zu brauchen heißt dann nicht mehr, beides zu bauen.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'RFC 8030 — Generic Event Delivery Using HTTP Push'
    url: 'https://datatracker.ietf.org/doc/html/rfc8030'
  - name: 'Push API — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/API/Push_API'
  - name: 'Push technology (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Push_technology'
  - name: 'Live Queries — Parse Server guide'
    url: 'https://docs.parseplatform.org/parse-server/guide/#live-queries'
cta:
  title: 'Ein Backend, beide Kanäle'
  text: 'Back4app liefert Push-Benachrichtigungen und Live Queries auf denselben Daten: Ein einziger Datenbankschreibvorgang fächert zu den Push-Gateways des Betriebssystems und zu jedem abonnierten WebSocket. Verdrahten Sie den afterSave-Trigger einmal und decken Sie jeden App-Zustand ab.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-29'
translationKey: push-notifications-vs-live-queries
---

**Eine Push-Benachrichtigung ist eine vom OS zugestellte Meldung, die geschlossene Apps erreicht; eine Live Query streamt Änderungen bei offener App.** Sie als Rivalen darzustellen ist der klassische Fehler – sie decken *disjunkte App-Zustände* ab, und die eigentliche Entwurfsfrage lautet nicht "welche von beiden", sondern "wo ist der Nutzer gerade?". Die meisten Apps, die sich wirklich nach Echtzeit anfühlen, betreiben beides und leiten anhand dieser Antwort weiter.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Push-Benachrichtigungen | Zustellung über das OS-Gateway (APNs, FCM) – erreicht geschlossene Apps, ~4 KB undurchsichtiger Payload, Best Effort |
| Live Queries | WebSocket-Abonnement – vollständige, berechtigungsgeprüfte Objekte, Echtzeit, App muss offen sein |
| Die Rivalität | Gibt es nicht – sie bedienen disjunkte App-Zustände und ergänzen sich, statt zu konkurrieren |
| Die Weiterleitungsregel | App offen → Live Query · App geschlossen → Push · Tipp auf den Push → öffnen, neu abonnieren, aufholen |
| Der Fehlerfall | Push als Datenkanal nutzen oder erwarten, dass Sockets den Prozess überleben |

## Beide Kanäle, im Code

Das Muster, auf das nahezu jede App für Messaging, Bestellungen und Warnungen zuläuft:

**JavaScript:**

```javascript
// 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
// 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.
```

**Swift:**

```swift
// 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.
```

**Kotlin:**

```kotlin
// 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.
```

Beachten Sie, was jede Hälfte erledigt: Das Abonnement liefert *Daten* – ganze Objekte, typisierte Ereignisse, in Echtzeit. Die Installation registriert sich für *Aufmerksamkeit* – das Recht, den Nutzer später zu unterbrechen, über eine Pipeline, die Ihre App nicht in der Hand hat.

## Zwei Zustellwege, zwei Eigentümer

Unterschiedlicher könnten die Wege kaum sein, und jede Eigenschaft in der Vergleichstabelle folgt daraus, wem die letzte Meile gehört.

Eine **Push-Benachrichtigung** verlässt Ihr Backend als Anfrage an ein vom Betriebssystem betriebenes Gateway – die Push-Gateways von iOS und Android (APNs, FCM) oder im Web ein Push-Dienst des Browsers, der [RFC 8030](https://datatracker.ietf.org/doc/html/rfc8030) spricht. Dem Gateway gehört die Zustellung: Es hält Nachrichten für Geräte im Offline-Zustand vor, fasst sie zusammen und drosselt unter Akkudruck, weckt Ihre App oder zeigt das Banner an. Diese geliehene Macht ist der ganze Sinn – *nur* das OS erreicht einen Prozess, der nicht läuft – und zugleich die ganze Einschränkung: Payloads auf rund 4 KB gedeckelt, Zustellung nach Best Effort, stille Hintergrundweckrufe tageweise rationiert und der Payload außerhalb des Berechtigungsmodells Ihres Backends.

Eine **Live Query** verlässt Ihre Vertrauensgrenze nie: Die App hält einen [WebSocket](/glossary/de/websockets/) zum Abonnement-Server des Backends, der jeden Datenbankschreibvorgang gegen die abonnierte Query prüft und typisierte Ereignisse pusht – create, update, enter, leave, delete – mit [pro Abonnent durchgesetzten ACLs](/glossary/de/live-queries-echtzeit/). Vollständige Objekte, Latenz in Echtzeit, keine nennenswerte Obergrenze für den Payload. Die Abhängigkeit im Gegenzug ist brutal: Das Abonnement ist Zustand innerhalb Ihres Prozesses, und wenn das OS die App suspendiert – was mobile Plattformen aggressiv tun –, sind Socket und Kanal weg.

```mermaid
flowchart TB
  accTitle: Echtzeit-Zustellung nach App-Zustand weiterleiten
  accDescr: Ein Datenbankschreibvorgang löst Backend-Logik aus. Ist die App des Empfängers offen, pusht eine Live Query das vollständige Objekt über einen WebSocket. Ist die App geschlossen, sendet das Backend einen kleinen Payload über das Push-Gateway des Betriebssystems, das eine Benachrichtigung anzeigt; ein Tipp darauf öffnet die App, die neu abonniert und per Abfrage aufholt.
  W["Datenbankschreibvorgang<br/>(Nachricht, Bestellung, Warnung)"] --> T["Backend-Trigger<br/>(afterSave)"]
  T -->|"App offen"| LQ["Push per Live Query<br/>vollständiges Objekt · WebSocket"]
  T -->|"App geschlossen"| GW["Push-Gateway des OS<br/>(APNs, FCM)"]
  GW --> N["Benachrichtigungsbanner<br/>~4 KB Payload"]
  N -->|"Tipp"| O["App öffnet sich →<br/>neu abonnieren + Aufhol-Abfrage"]
  LQ --> UI["Bildschirm aktualisiert sich an Ort und Stelle"]
  O --> UI
```

## Push-Benachrichtigungen vs. Live Queries

| | Push-Benachrichtigungen | Live-Query-Abonnements |
| --- | --- | --- |
| Erreicht eine geschlossene App | **Ja – die entscheidende Fähigkeit** | Nein – das Abonnement stirbt mit dem Prozess |
| Payload | ~4 KB, undurchsichtig für Ihre ACLs | Vollständige Objekte, pro Abonnent berechtigungsgeprüft |
| Zustellgarantie | Best Effort; zusammengefasst, gedrosselt, verwerfbar | Zuverlässig, solange verbunden; Aufholen nach Lücken nötig |
| Latenz | Sekundenbereich, gatewayabhängig | Echtzeit (~RTT) |
| Eigentümer des Transports | Das OS und sein Gateway | Die WebSocket-Flotte Ihres Backends |
| Zustimmung des Nutzers | Systemabfrage; vom Nutzer widerrufbar | Keine nötig – es sind nur die Daten Ihrer App |
| Kosten bei Missbrauch | Benachrichtigungsmüdigkeit, Deinstallationen | Last auf Akku und Sockets bei zu vielen Abonnements |
| Gebaut für | Aufmerksamkeit und Rückgewinnung | Daten und Zustand in der App |

Die Zeilen ergänzen sich sauber, weil die beiden Kanäle verschiedene Fragen beantworten: Push beantwortet *"Wie erreiche ich den Nutzer?"*, Live Queries beantworten *"Wie bleibt der Bildschirm wahrhaftig?"* – weshalb der [Vergleich auf Transportebene](/glossary/de/sse-vs-websockets-vs-polling/) zwischen SSE, WebSockets und Polling vollständig innerhalb der zweiten Frage liegt.

## Die Übergabe: wo Apps tatsächlich kaputtgehen

Die Fehler sitzen an der Naht zwischen den Kanälen. Ein Nutzer tippt auf einen Push zu einer Nachricht, die *auch* per Live Query zugestellt wurde, bevor die App suspendiert wurde – deduplizieren Sie nach Objekt-ID, nicht nach Kanal. Ein Push trifft zu Daten ein, auf die der Nutzer keinen Zugriff mehr hat – holen Sie sie beim Öffnen über die normale API und lassen Sie die ACLs entscheiden, vertrauen Sie niemals dem Payload. Die App war drei Tage lang geschlossen – die wieder geöffnete App kann eine Lücke nicht aus Pushes wiedergeben (Benachrichtigungen sind kein Journal), also lautet die Übergabe immer *neu abonnieren, dann die Basisabfrage erneut ausführen*, um die Wahrheit neu aufzubauen, während die [Registrierung des Push-Tokens](/glossary/de/push-benachrichtigungen/) im Hintergrund aktuell gehalten wird. Entwerfen Sie die Naht einmal, und beide Kanäle werden langweilig – genau das ist das Ziel.

## Typische Anwendungsfälle

- **Chat und Messaging** – die Live Query stellt die geöffnete Unterhaltung dar; der Push trägt "neue Nachricht" durch den geschlossenen Zustand. Die Zwei-Kanal-App schlechthin.
- **Bestell- und Lieferverfolgung** – der geöffnete Verfolgungsbildschirm abonniert; der Wechsel auf "zugestellt" bei geschlossener App kommt als Push.
- **Betriebliche Alarmierung** – Konsolen der Rufbereitschaft abonnieren für die Wandanzeige; der Weg zum Pager ist Push, weil um 3 Uhr nachts niemand die App offen hält.
- **Auktionen und Drops** – Preisbewegungen live in der App; überboten zu werden, während man weg ist, ist ein Push mit Deep Link zurück in den Live-Bildschirm.
- **Soziale Interaktion** – Likes und Antworten landen als Push zur Rückgewinnung; der geöffnete Feed geht per Abonnement live.

## Welchen Kanal sollten Sie verwenden? Entscheidungsmatrix

| Ihre Situation | Greifen Sie zu |
| --- | --- |
| Der Bildschirm ist offen und muss aktuell bleiben | Live Query |
| Das Ereignis tritt bei geschlossener App ein und der Nutzer sollte es wissen | Push-Benachrichtigung |
| Der Payload ist sensibel oder berechtigungspflichtig | Live Query – oder nur Kennungen per Push, beim Öffnen nachladen |
| Sie brauchen garantierte, geordnete Zustellung von Daten | Keiner allein – Aufholen per Abfrage beim Öffnen, Kanäle als Beschleuniger |
| Ein Badge oder einen Zähler in der App in Echtzeit aktualisieren | Live Query |
| Nutzer zurückgewinnen, die die App seit Tagen nicht geöffnet haben | Push – der einzige Kanal, der das kann |
| Kiosk oder Wandanzeige, die nie schläft | Nur Live Query; Push bringt nichts hinzu |

## Grenzen und Trade-offs

- **Push ist kein Datenkanal.** Payload-Grenzen, undurchsichtiges Routing außerhalb Ihrer ACLs und das Zusammenfassen machen ihn strukturell ungeeignet, Zustand zu tragen – senden Sie Verweise, holen Sie die Wahrheit beim Öffnen.
- **Push-Zustellung ist eine Wahrscheinlichkeit, kein Versprechen.** Akku-Optimierer, entzogene Berechtigungen und Drosselung durch das Gateway verwerfen Nachrichten allesamt stillschweigend; alles, was nicht verloren gehen darf, braucht einen Abgleichspfad per Abfrage.
- **Live Queries enden an der Prozessgrenze.** Kein Socket überlebt die Suspendierung; ein Abonnement für einen dauerhaft aktiven Kanal zu halten ist die falsche Annahme hinter den meisten "uns sind Ereignisse entgangen"-Fehlern.
- **Beide Kanäle belasten den Client.** Zu breite Abonnements verbrennen Akku und serverseitigen Abgleich; zu eifriger Push verbrennt Wohlwollen – die Deinstallation ist das Rate Limiting des Nutzers.
- **Die Naht liegt in Ihrer Verantwortung.** Deduplizierung, Aufhol-Abfragen und die Auffrischung der Token sind Anwendungslogik; keiner der beiden Kanäle liefert sie gratis mit.

## Push und Live Queries mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Beide Kanäle sind eingebaut und teilen sich einen Schreibpfad: Ein Cloud-Code-Trigger `afterSave` auf demselben Datenbankschreibvorgang kann den Push senden – über die Gateway-Anbindungen der Plattform, mit Adressierung nach Gerät und Kanal –, während [Live Query](/glossary/de/live-queries-echtzeit/) das vollständige Objekt automatisch an jeden abonnierten, berechtigungsgeprüften Client fächert. Das Weiterleitungsdiagramm oben schrumpft auf einen Trigger und einen Abonnementaufruf, und die Logik an der Naht – Aufhol-Abfragen, Token-Registrierung über die Installation-Klasse – läuft durch dieselben SDKs, die die Code-Tabs zeigen.