Vad är LISTEN och NOTIFY?

Question

Accepted Answer

**`LISTEN`** och **`NOTIFY`** tillhandahåller ett inbyggt **publish/subscribe**-meddelandesystem i PostgreSQL — en session kan skicka ett meddelande på en kanal, och andra sessioner som lyssnar på den kanalen mottar det direkt. Det är ett lättviktigt sätt att pusha realtidshändelser från databasen utan avsökning.

## Den grundläggande mekanismen

```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 prenumererar på en kanal; NOTIFY publicerar på den (med en valfri textlast). Lyssnare notifieras asynkront — ingen avsökning behövs.

## Att utlösa NOTIFY automatiskt (ett vanligt mönster)

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

Att kombinera NOTIFY med en **trigger** låter databasen automatiskt pusha händelser när data ändras (ny order, statusuppdatering) — programservrar som lyssnar på kanalen reagerar i realtid.

## Hur applikationer använder det

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

## Begränsningar att känna till

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

## Varför det spelar roll

`LISTEN`/`NOTIFY` är en användbar, något mindre känd PostgreSQL-funktion som tillhandahåller **inbyggt pub/sub-meddelandesystem**, värdefullt för att lägga till **realtidsreaktivitet** till applikationer utan avsökning.

Kärnvärdet är att databasen kan **pusha händelser** till lyssnande applikationssessioner direkt när något inträffar (en ny order, en statusändring) — vanligtvis kombinerat med **triggers** så att dataändringar automatiskt notifierar lyssnare, som programservrar reagerar på (pushing till websockets, invalidering av cacheminnen, utlösning av bakgrundsarbete).

Detta är värdefullt eftersom det tillhandahåller beteende för realtidshändelsedrivning utan ineffektiviteten med att **avsöka** databasen upprepade gånger för att kontrollera om ändringar har gjorts (ett vanligt, slösaktigt mönster som LISTEN/NOTIFY elegant ersätter).

Att förstå mekanismen (LISTEN för att prenumerera, NOTIFY för att publicera, med triggers för automatisk notifiering vid dataändringar) och hur applikationer använder den (lyssning på händelser för att driva realtidsreaktioner) är användbart för att bygga responsiva, händelsedrivna applikationer med bara PostgreSQL.

Lika viktigt är att känna till **begränsningarna**: notifieringar är **inte beständiga** (försvinner om ingen lyssnar — inga varaktighetsgarantier), har små lastor och utlöses bara efter commit — så det passar för lättviktig realtidssignalering, *inte* en ersättning för en beständig meddelandekö (RabbitMQ, Kafka) när tillförlitlighet och persistens spelar roll.

Då realtidsreaktivitet är ett vanligt behov och LISTEN/NOTIFY erbjuder ett inbyggt, avsökningsfritt sätt att uppnå det för lättviktiga fall, är det värdefullt att förstå det — pub/sub-mekanismen, triggermönstret, och kritiskt dess begränsningar (när det räcker jämfört med när en verklig meddelandekö behövs) — värdefullt, praktiskt relevant PostgreSQL-kunskap för att bygga händelsedrivna applikationer, en användbar inbyggd funktion som ofta förbises.