Was sind LISTEN und NOTIFY?

Question

Accepted Answer

**`LISTEN`** und **`NOTIFY`** bieten ein eingebautes **Publish/Subscribe**-Messaging-System in PostgreSQL – eine Sitzung kann eine Benachrichtigung auf einem Kanal senden, und andere Sitzungen, die auf diesem Kanal lauschen, erhalten sie sofort. Es ist eine leichte Methode, um Echtzeit-Ereignisse aus der Datenbank zu übertragen, ohne Abfragen durchführen zu müssen.

## Der grundlegende Mechanismus

```sql
-- a session SUBSCRIBES to a channel
LISTEN order_created;

-- another session/transaction PUBLISHES a notification (with an optional payload)
NOTIFY order_created, 'order id 123';
-- → all sessions listening on 'order_created' receive the message immediately
```

LISTEN abonniert einen Kanal; NOTIFY publiziert darauf (mit einer optionalen Textnutzlast). Listener werden asynchron benachrichtigt – keine Abfragen erforderlich.

## NOTIFY automatisch auslösen (ein häufiges Muster)

```sql
-- a trigger that notifies whenever a row is inserted
CREATE FUNCTION notify_new_order() RETURNS trigger AS $$
BEGIN
  PERFORM pg_notify('order_created', NEW.id::text);   -- notify with the new id
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER order_notify AFTER INSERT ON orders
  FOR EACH ROW EXECUTE FUNCTION notify_new_order();
-- now inserting an order automatically pushes a notification to listeners
```

Durch die Kombination von NOTIFY mit einem **Trigger** kann die Datenbank automatisch Ereignisse übertragen, wenn sich Daten ändern (neue Bestellung, Statusaktualisierung) – Anwendungsserver, die auf dem Kanal lauschen, reagieren in Echtzeit.

## Wie Anwendungen es nutzen

```text
Application code (Node, Python, etc.) opens a connection and LISTENs on a channel.
When a NOTIFY fires (e.g. from a trigger on data change), the app receives the event
and reacts — pushing to websockets, invalidating a cache, triggering a job, etc.
→ Real-time reactions to database changes WITHOUT polling the database.
```

## Einschränkungen, die Sie kennen sollten

```text
✗ Notifications are NOT persisted — if no one is listening, the message is LOST
  (no durability/queue guarantees like a real message broker)
✗ Payload is small (limited size); delivered only after the transaction COMMITS
→ Good for lightweight real-time signaling; for durable/reliable messaging use a
  proper broker (RabbitMQ, Kafka) or a queue table.
```

## Warum es wichtig ist

`LISTEN`/`NOTIFY` ist eine nützliche, etwas weniger bekannte PostgreSQL-Funktion, die **eingebautes Pub/Sub-Messaging** bietet und für das Hinzufügen von **Echtzeit-Reaktivität** zu Anwendungen ohne Abfragen wertvoll ist.

Der Kernwert liegt darin, dass die Datenbank **Ereignisse** an lauschende Anwendungssitzungen übertragen kann, wenn etwas passiert (eine neue Bestellung, eine Statusänderung) – typischerweise kombiniert mit **Triggern**, sodass Datenänderungen Listener automatisch benachrichtigen, worauf Anwendungsserver reagieren (Push zu WebSockets, Cache-Invalidierung, Triggern von Hintergrundwork).

Dies ist wertvoll, weil es ereignisgesteuerte Echtzeitverhalten ermöglicht, ohne die Ineffizienz von wiederholten **Abfragen** der Datenbank auf Änderungen zu überprüfen (ein häufiges, verschwenderisches Muster, das LISTEN/NOTIFY elegant ersetzt).

Das Verständnis des Mechanismus (LISTEN zum Abonnieren, NOTIFY zum Publizieren, mit Triggern für automatische Benachrichtigung bei Datenänderungen) und die Nutzung durch Anwendungen (Lauschen auf Ereignisse, um Echtzeit-Reaktionen zu treiben) ist nützlich für den Aufbau reaktiver, ereignisgesteuerter Anwendungen mit nur PostgreSQL.

Ebenso wichtig ist die Kenntnis der **Einschränkungen**: Benachrichtigungen werden **nicht persistiert** (gehen verloren, wenn niemand lauscht – keine Dauerhaftigkeitsgarantien), haben kleine Nutzlasten und feuern nur nach dem Commit – daher ist es für leichte Echtzeit-Signalisierung geeignet, *nicht* als Ersatz für einen dauerhaften Message Broker (RabbitMQ, Kafka), wenn Zuverlässigkeit und Persistierung wichtig sind.

Da Echtzeit-Reaktivität ein häufiges Bedürfnis ist und LISTEN/NOTIFY eine eingebaute, abfragefreie Methode bietet, um es für leichte Fälle zu erreichen, ist das Verständnis dafür – der Pub/Sub-Mechanismus, das Trigger-Muster und entscheidend seine Einschränkungen (wann es ausreicht gegenüber wann ein echter Broker erforderlich ist) – wertvolles, praktisch relevantes PostgreSQL-Wissen für den Aufbau ereignisgesteuerter Anwendungen, eine nützliche eingebaute Funktion, die oft übersehen wird.