LISTEN and NOTIFY provide a built-in publish/subscribe messaging system in PostgreSQL — one session can send a notification on a channel, and other sessions listening on that channel receive it instantly. It's a lightweight way to push real-time events from the database without polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN subscribes to a channel; NOTIFY publishes to it (with an optional text payload). Listeners get notified asynchronously — no polling needed.
-- 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
Combining NOTIFY with a trigger lets the database automatically push events when data changes (new order, status update) — application servers listening on the channel react 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 a useful, somewhat lesser-known PostgreSQL feature that provides built-in pub/sub messaging, valuable for adding real-time reactivity to applications without polling.
The core value is enabling the database to push events to listening application sessions instantly when something happens (a new order, a status change) — typically combined with triggers so data changes automatically notify listeners, which application servers react to (pushing to websockets, invalidating caches, triggering background work).
This is valuable because it provides real-time event-driven behavior without the inefficiency of polling the database repeatedly to check for changes (a common, wasteful pattern that LISTEN/NOTIFY elegantly replaces).
Understanding the mechanism (LISTEN to subscribe, NOTIFY to publish, with triggers for automatic notification on data changes) and how applications use it (listening for events to drive real-time reactions) is useful for building responsive, event-driven applications using just PostgreSQL.
Equally important is knowing the limitations: notifications are not persisted (lost if no one is listening — no durability guarantees), have small payloads, and only fire after commit — so it's suited to lightweight real-time signaling, not a replacement for a durable message broker (RabbitMQ, Kafka) when reliability and persistence matter.
Since real-time reactivity is a common need and LISTEN/NOTIFY offers a built-in, polling-free way to achieve it for lightweight cases, understanding it — the pub/sub mechanism, the trigger pattern, and crucially its limitations (when it suffices vs when a real broker is needed) — is valuable, practically-relevant PostgreSQL knowledge for building event-driven applications, a useful built-in feature that's often overlooked.