LISTEN y NOTIFY proporcionan un sistema de mensajería publish/subscribe integrado en PostgreSQL — una sesión puede enviar una notificación en un canal, y otras sesiones escuchando en ese canal la reciben instantáneamente. Es una forma ligera de enviar eventos en tiempo real desde la base de datos sin polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN se suscribe a un canal; NOTIFY publica en él (con un payload de texto opcional). Los oyentes reciben notificaciones de forma asincrónica — no se requiere polling.
-- 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
Combinar NOTIFY con un trigger permite que la base de datos envíe automáticamente eventos cuando los datos cambian (nueva orden, actualización de estado) — los servidores de aplicación escuchando en el canal reaccionan en tiempo real.
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 es una característica útil y relativamente menos conocida de PostgreSQL que proporciona mensajería pub/sub integrada, valiosa para añadir reactividad en tiempo real a las aplicaciones sin polling.
El valor principal es permitir que la base de datos envíe eventos a sesiones de aplicación escuchando instantáneamente cuando algo ocurre (una nueva orden, un cambio de estado) — típicamente combinado con triggers para que los cambios de datos notifiquen automáticamente a los oyentes, a los que los servidores de aplicación reaccionan (enviando a websockets, invalidando cachés, disparando trabajo en segundo plano).
Esto es valioso porque proporciona comportamiento impulsado por eventos en tiempo real sin la ineficiencia de hacer polling a la base de datos repetidamente para verificar cambios (un patrón común y desaprovechador que LISTEN/NOTIFY reemplaza elegantemente).
Comprender el mecanismo (LISTEN para suscribirse, NOTIFY para publicar, con triggers para notificación automática en cambios de datos) y cómo las aplicaciones lo usan (escuchando eventos para impulsar reacciones en tiempo real) es útil para construir aplicaciones responsivas e impulsadas por eventos usando solo PostgreSQL.
Igualmente importante es conocer las limitaciones: las notificaciones no se persisten (se pierden si nadie está escuchando — sin garantías de durabilidad), tienen payloads pequeños, y solo se disparan después de commit — así que es adecuado para señalización ligera en tiempo real, no un reemplazo para un message broker duradero (RabbitMQ, Kafka) cuando importan la confiabilidad y la persistencia.
Puesto que la reactividad en tiempo real es una necesidad común y LISTEN/NOTIFY ofrece una forma integrada y libre de polling para lograrla en casos ligeros, entenderlo — el mecanismo pub/sub, el patrón de trigger, y crucialmente sus limitaciones (cuándo es suficiente vs cuándo se necesita un broker real) — es conocimiento PostgreSQL valioso y prácticamente relevante para construir aplicaciones impulsadas por eventos, una característica integrada útil que frecuentemente se pasa por alto.