---
term: 'Live Queries in Echtzeit'
seoTitle: 'Live Queries: Echtzeit-Abonnements für Datenbankabfragen'
headline: 'Was sind Live Queries in Echtzeit?'
slug: live-queries-echtzeit
category: api-realtime
shortDefinition: 'Eine Live Query ist ein Abonnement auf eine Datenbankabfrage: Der Server sendet create-, update- und delete-Ereignisse für passende Zeilen in Echtzeit.'
relatedTerms:
  - websockets-real-time-sync
  - event-driven-architecture
  - push-notifications-apns-fcm
  - database-triggers-beforesave-aftersave
contrastsWith:
  - websockets-real-time-sync
faq:
  - question: 'Was ist eine Live Query?'
    answer: 'Ein dauerhaftes Abonnement auf eine Datenbankabfrage: Statt einmal zu fragen und eine Momentaufnahme zu erhalten, abonnieren Sie die Abfrage, und der Server sendet jedes Mal ein Ereignis, wenn sich ihre Ergebnismenge ändert – ein passender Datensatz wird angelegt, geändert, gelöscht oder so bearbeitet, dass er in die Ergebnisse hinein- oder aus ihnen herausfällt. Ihr Bildschirm hört auf zu pollen und fängt an zuzuhören.'
  - question: 'Worin unterscheidet sich eine Live Query von einer normalen Abfrage?'
    answer: 'In der Lebensdauer. Eine normale Abfrage läuft, liefert ein Ergebnis und ist fertig – ihre Antwort beginnt sofort zu altern. Eine Live Query bleibt auf dem Server registriert: Die ersten Ergebnisse kommen auf demselben Weg, danach halten gezielte Änderungsereignisse sie aktuell, bis Sie das Abonnement beenden. Dieselbe Prädikatssprache, das umgekehrte Verhältnis zur Zeit.'
  - question: 'Wie funktionieren Live Queries unter der Haube?'
    answer: 'Zwei Hälften, die zusammengefügt werden: eine Änderungsquelle und ein Transport. Die Datenbank gibt ihren Strom von Schreibvorgängen aus – über Change Streams, Replikationsprotokolle oder Trigger – und ein Abonnement-Server gleicht jede Änderung mit den registrierten Abfrageprädikaten ab und sendet die relevanten Ereignisse über WebSockets an die Abonnenten. Das Client-SDK kapselt den Lebenszyklus des Sockets, sodass Ihr Code nur typisierte Ereignisse sieht.'
  - question: 'Was sind die Ereignisse enter und leave?'
    answer: 'Das subtile Paar, das Abfrage-Abonnements präzise macht. Enter wird ausgelöst, wenn ein bestehender Datensatz so bearbeitet wird, dass er Ihrem Prädikat zu entsprechen beginnt; leave, wenn eine Bearbeitung ihn aufhören lässt zu entsprechen. Eine Aufgabe, die Ihnen neu zugewiesen wird, betritt Ihr Abonnement "mir zugewiesen", ohne angelegt worden zu sein; wird sie weitergereicht, verlässt sie es, ohne gelöscht worden zu sein. Create, update und delete decken den Rest ab.'
  - question: 'Warum sind Live Queries besser als Polling?'
    answer: 'Auf drei Arten gleichzeitig: Latenz – Änderungen kommen in Echtzeit an statt beim nächsten Poll; Bandbreite – Ereignisse tragen nur das Geänderte statt alles erneut abzurufen; und Last – der Server gleicht pro Änderung ab, statt pro Client und Intervall vollständige Abfragen auszuführen. Alle paar Sekunden zu pollen ist eine Nachahmung; Abonnements sind die Sache selbst.'
  - question: 'Was bringen Live Queries gegenüber rohen WebSockets?'
    answer: 'Das Abfragegehirn. Ein roher Socket bewegt Nachrichten; alles andere – welche Clients sich für welche Änderungen interessieren, was die Ereignisse bedeuten, wer was sehen darf, das Nachholen nach einer Wiederverbindung – ist Code, den Sie schreiben. Eine Live-Query-Schicht führt den Prädikatsabgleich serverseitig aus, typisiert die Ereignisse, setzt Berechtigungen pro Abonnent durch und verwaltet den Lebenszyklus des Sockets. Das ist der Unterschied zwischen einem Transport und einem Feature.'
  - question: 'Sind GraphQL-Subscriptions dasselbe wie Live Queries?'
    answer: 'Dieselbe Familie, ein anderer Auslöser. GraphQL-Subscriptions feuern bei benannten Ereignissen, die Sie definieren – eine Mutation veröffentlicht, Abonnenten empfangen. Live Queries feuern bei Änderungen der Ergebnismenge einer Abfrage – keine Ereignisverdrahtung, das Prädikat ist das Abonnement. Beide laufen über WebSockets; Live Queries tauschen den expliziten Ereignisentwurf gegen die automatische Abdeckung jedes Schreibpfads.'
  - question: 'Wie skalieren Live Queries?'
    answer: 'Auf zwei Achsen: Verbindungen – Tausende offener Sockets, verteilt über Abonnement-Server hinter einem Pub/Sub-Backplane – und Abgleich: Jeder Schreibvorgang wird gegen die registrierten Prädikate geprüft, weshalb selektive Abonnements auf indizierten Feldern zählen. Verwaltete Plattformen betreiben beide Achsen für Sie; die Disziplin auf Client-Seite besteht darin, eng zu abonnieren und beim Schließen eines Bildschirms wieder abzubestellen.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'LiveQuery documentation'
    url: 'https://docs.parseplatform.org/parse-server/guide/#live-queries'
  - name: 'MongoDB change streams documentation'
    url: 'https://www.mongodb.com/docs/manual/changestreams/'
  - name: 'LiveQuery protocol specification'
    url: 'https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification'
  - name: 'Back4app Live Query example'
    url: 'https://www.back4app.com/docs/platform/parse-server-live-query-example'
cta:
  title: 'Daten abonnieren statt Infrastruktur'
  text: 'Back4app Live Queries machen aus jeder Abfrage ein Abonnement: fünf typisierte Ereignisse, ACLs pro Abonnent durchgesetzt und die WebSocket-Flotte von der Plattform verwaltet. Echtzeit-Features in der Zeit, die es braucht, die Abfrage zu schreiben, die Sie ohnehin hatten.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-23'
translationKey: real-time-live-queries
---

**Eine Live Query ist ein Abonnement auf eine Datenbankabfrage: Der Server sendet create-, update- und delete-Ereignisse für passende Zeilen in Echtzeit.** Es ist die fehlende Zeitform des Datenbankzugriffs: Normale Abfragen sprechen in der Vergangenheit ("was passte, als ich fragte"), Live Queries sprechen in der laufenden Gegenwart ("was passt, während es sich ändert"). Der Bildschirm hört auf zu fragen und bleibt einfach richtig.

## Das Wichtigste in Kürze

| Frage | Antwort |
| --- | --- |
| Was es ist | Eine dauerhafte Abfrage – einmal abonnieren, jede Änderung ihrer Ergebnisse empfangen |
| Die fünf Ereignisse | create · update · delete · **enter** · **leave** |
| Unter der Haube | Change Stream der Datenbank → Prädikatsabgleich → WebSocket-Push |
| vs. Polling | Echtzeit-Latenz, Payloads in Delta-Größe, keine Abfragelast pro Intervall |
| vs. rohe Sockets | Die Abfrageschicht: Abgleich, typisierte Ereignisse, Berechtigungen, Wiederverbindungen |

## Das Abonnement, in Code

Der entscheidende Handgriff – nehmen Sie die Abfrage, die Sie ohnehin hatten, und abonnieren Sie sie:

**JavaScript:**

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

**Swift:**

```swift
// 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)
  }
}
```

**Kotlin:**

```kotlin
// 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) }
```

Das Vokabular der Ereignisse verdient eine eigene Tabelle, denn **enter** und **leave** machen daraus ein Abonnement auf eine *Abfrage* statt einer Tabellenbenachrichtigung:

| Ereignis | Wird ausgelöst, wenn … | Beispiel (abonniert auf "mir zugewiesene Aufgaben") |
| --- | --- | --- |
| create | Ein neuer Datensatz passt | Eine Aufgabe wird für Sie angelegt |
| update | Ein passender Datensatz ändert sich | Der Status Ihrer Aufgabe wechselt |
| **enter** | Eine Bearbeitung lässt einen bestehenden Datensatz passen | Eine Aufgabe wird Ihnen *neu zugewiesen* |
| **leave** | Eine Bearbeitung lässt einen Treffer aufhören zu passen | Ihre Aufgabe wird weitergereicht |
| delete | Ein passender Datensatz wird gelöscht | Die Aufgabe wird entfernt |

## Die Pipeline hinter dem Push

```mermaid
flowchart LR
  accTitle: Wie Live Queries von Anfang bis Ende funktionieren
  accDescr: Schreibvorgänge der Datenbank fließen in einen Change Stream; ein Abonnement-Server gleicht jede Änderung mit den registrierten Abfrageprädikaten ab und sendet typisierte Ereignisse über WebSockets an die abonnierten Clients, wobei die Berechtigungen pro Abonnent geprüft werden.
  W["Schreibvorgänge<br/>(jeder Client, jede API)"] --> DB[("Datenbank")]
  DB --> CS["Change Stream<br/>(Oplog / WAL / Trigger)"]
  CS --> M["Abonnement-Server<br/>Prädikatsabgleich + ACL-Prüfung"]
  M -->|"WebSocket-Push"| C1["Abonnent A"]
  M -->|"WebSocket-Push"| C2["Abonnent B"]
```

Zwei Hälften, sauber trennbar: die **Änderungsquelle** – der eigene Schreib-Feed der Datenbank ([Change Streams](https://www.mongodb.com/docs/manual/changestreams/) in dokumentenorientierten Speichern, anderswo Replikationsprotokolle) – und die **Abgleichsschicht**, die jede Änderung gegen jedes registrierte Prädikat prüft und genau an die Abonnenten sendet, deren Ergebnisse sich geändert haben, mit Berechtigungsprüfung pro Abonnent. Das [offene LiveQuery-Protokoll](https://github.com/parse-community/parse-server/wiki/Parse-LiveQuery-Protocol-Specification) ist eine gut lesbare Referenzimplementierung dieser gesamten Form.

## Live Queries vs. Polling vs. SSE vs. WebSockets

| Ansatz | Latenz | Payload | Serverkosten | Was Sie bauen |
| --- | --- | --- | --- | --- |
| Polling | Poll-Intervall | Jedes Mal vollständig neu laden | Abfragen × Clients × Frequenz | Timer, Diffing |
| Long Polling | Nahezu Echtzeit | Vollständige Antwort pro Ereignis | Gehaltene Verbindungen | Rückfall-Infrastruktur |
| SSE | Echtzeit | Delta | Streams, einseitig | Ereignisentwurf |
| Rohe WebSockets | Echtzeit | Was immer Sie definieren | Verbindungen + Ihr Fan-out | **Alles** |
| **Live Queries** | **Echtzeit** | **Ereignisse pro Änderung** | **Abgleich + Verbindungen (verwaltet)** | **Die Abfrage** |

Die letzte Spalte ist das Argument: Mit [rohen Sockets](/glossary/de/websockets/) bauen Sie das Nachrichtenprotokoll, das Routing, die Berechtigungsprüfungen und das Nachholen nach einer Wiederverbindung; mit Live Queries ist das *Prädikat das Protokoll*, und die Plattform besitzt den Rest.

## Typische Anwendungsfälle

- **Chat und Posteingänge** – abonnieren Sie die Nachrichten einer Unterhaltung; die Ankunft ist ein Ereignis, keine Aktualisierung.
- **Live-Dashboards** – Bestellungen, Kennzahlen, Fuhrparks: Die Abfrage definiert die Ansicht, Ereignisse halten sie wahr.
- **Kollaborative Apps** – gemeinsame Aufgabenbretter und Dokumente, in denen sich die Änderungen von fünf Personen im Sekundentakt verschränken.
- **Präsenz und Status** – wer online ist, was gerade läuft – hier leisten enter und leave ihre präzise Arbeit.
- **Betriebsbildschirme** – Support-Konsolen und Admin-Ansichten, die die Produktion *jetzt* abbilden müssen, nicht zum Zeitpunkt der letzten Aktualisierung.

## Pollen, pushen oder abonnieren? Eine Entscheidungsmatrix

| Greifen Sie zu Live Queries, wenn … | Einfachere Werkzeuge genügen, wenn … |
| --- | --- |
| Nutzer gemeinsame, sich ändernde Daten betrachten | Daten sich selten ändern – behutsam pollen oder beim Fokus neu laden |
| Änderungen von vielen Schreibern und Pfaden kommen | Ein einzelner Schreiber ebenso gut per SSE senden könnte |
| Die Ansicht von Natur aus eine Abfrage ist | Die Nachricht keine Datenform hat (dann Sockets direkt nutzen) |
| Berechtigungen steuern müssen, wer was sieht | Alles ein öffentlicher Broadcast ist |
| Sie die Fan-out-Infrastruktur lieber nicht besitzen | Sie ohnehin eine Echtzeit-Plattform betreiben |

Die Disziplin auf Client-Seite, die Abonnements gesund hält, wie Sie sich auch entscheiden: *eng* abonnieren (selektive Prädikate auf indizierten Feldern) und abbestellen, wenn der Bildschirm geschlossen wird – dauerhafte Abfragen sind Serverzustand, und Bildschirme, die sie lecken, sammeln unsichtbar Kosten an.

## Grenzen und Trade-offs

- **Der Abgleich ist eine echte Arbeitslast.** Jeder Schreibvorgang wird gegen die registrierten Prädikate geprüft; Tausende breiter Abonnements auf stark genutzten Klassen vervielfachen das – Selektivität ist der Hebel.
- **Verbindungen sind Zustand.** Die Socket-Flotte braucht Affinität, Heartbeats und Fan-out-Backplanes – verwaltete Plattformen existieren genau deshalb, weil das undifferenzierte Schwerstarbeit ist.
- **Wiederverbindungen brauchen ein Nachholen.** Ein Client, der offline war, hat Ereignisse verpasst; robuste Abläufe führen beim erneuten Abonnieren die Basisabfrage noch einmal aus, statt darauf zu vertrauen, dass die Lücke ruhig war.
- **Reihenfolge und Zustellung haben At-least-once-Charakter.** Idempotente Ereignis-Handler (nach Objekt-ID anwenden, nicht anhängen) verkraften das gelegentliche Duplikat anstandslos.
- **Nicht alles will ein Abonnement.** Selten betrachtete, selten geänderte Daten sind Polling-Gebiet; Live Queries verdienen ihre Kosten dort, wo Blicke und Schreibvorgänge beide häufig sind.

## 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. [Live Query](https://www.back4app.com/docs/platform/parse-server-live-query-example) ist die zugehörige Echtzeit-Schicht, und die Code-Tabs oben sind die gesamte Geschichte auf Client-Seite: derselbe Query Builder, den Sie schon verwenden, ein einziger Abonnement-Aufruf, fünf typisierte Ereignisse – mit ACLs, die pro Abonnent geprüft werden, sodass Echtzeit das Berechtigungsmodell nie umgeht, und mit WebSocket-Flotte, Change Streams und Fan-out als verwaltete Infrastruktur. Aktivieren Sie Live Query für eine Klasse im Dashboard, abonnieren Sie aus jedem beliebigen SDK, und die laufende Gegenwart wird ein Feature statt eines Projekts.