LISTEN en NOTIFY bieden een ingebouwd publish/subscribe berichtsysteem in PostgreSQL — één sessie kan een notificatie op een kanaal verzenden, en andere sessies die naar dat kanaal luisteren, ontvangen deze onmiddellijk. Het is een lichtgewicht manier om real-time events vanuit de database te pushen zonder polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN abonneert zich op een kanaal; NOTIFY publiceert ernaar (met een optionele tekstlading). Listeners krijgen asynchrone meldingen — geen polling nodig.
-- 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
NOTIFY combineren met een trigger stelt de database in staat om automatisch events te pushen wanneer gegevens veranderen (nieuwe bestelling, statusupdate) — application servers die op het kanaal luisteren, reageren in real-time.
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.
✗ 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.
LISTEN/NOTIFY is een nuttige, enigszins minder bekende PostgreSQL-functie die ingebouwde pub/sub messaging biedt, waardevol voor het toevoegen van real-time reactieve gedrag aan toepassingen zonder polling.
De kernwaarde is dat de database events kan pushen naar luisterende applicatiesessies zodra iets gebeurt (een nieuwe bestelling, een statusverandering) — typisch gecombineerd met triggers zodat gegevenswijzigingen automatisch listeners notificeren, waarop application servers reageren (pushen naar websockets, caches ongeldig maken, achtergrondwerk triggeren).
Dit is waardevol omdat het real-time event-driven gedrag biedt zonder de inefficiëntie van polling van de database herhaaldelijk om op wijzigingen te controleren (een veelgebruikt, verspillend patroon dat LISTEN/NOTIFY elegant vervangt).
Het begrijpen van het mechanisme (LISTEN om je in te schrijven, NOTIFY om te publiceren, met triggers voor automatische meldingen bij gegevenswijzigingen) en hoe toepassingen het gebruiken (luisteren naar events om real-time reacties uit te voeren) is nuttig voor het bouwen van responsieve, event-driven toepassingen met alleen PostgreSQL.
Evenso belangrijk is het kennen van de beperkingen: meldingen worden niet opgeslagen (verloren als niemand luistert — geen duurzaamheidsgaranties), hebben kleine lasten, en vuren pas na commit — dus het is geschikt voor lichtgewicht real-time signalering, niet als vervanging voor een duurzame message broker (RabbitMQ, Kafka) wanneer betrouwbaarheid en persistentie belangrijk zijn.
Omdat real-time reactief gedrag een veelgebruikte behoefte is en LISTEN/NOTIFY een ingebouwde, polling-vrije manier biedt om dit voor lichtgewicht gevallen te bereiken, is het begrijpen ervan — het pub/sub-mechanisme, het triggerpatroon, en crucaal de beperkingen ervan (wanneer het voldoende is versus wanneer een echte broker nodig is) — waardevol, praktisch relevant PostgreSQL-kennis voor het bouwen van event-driven toepassingen, een nuttige ingebouwde functie die vaak over het hoofd wordt gezien.