LISTEN e NOTIFY fornecem um sistema de mensagens de publish/subscribe integrado no PostgreSQL — uma sessão pode enviar uma notificação em um canal, e outras sessões ouvindo esse canal a recebem instantaneamente. É uma forma leve de enviar eventos em tempo real do banco de dados sem polling.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN se inscreve em um canal; NOTIFY publica nele (com um payload de texto opcional). Os ouvintes são notificados assincronamente — sem necessidade de 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
Combinando NOTIFY com um trigger permite que o banco de dados empurre eventos automaticamente quando os dados mudam (novo pedido, atualização de status) — servidores de aplicação ouvindo o canal reagem em tempo 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 é um recurso útil e pouco conhecido do PostgreSQL que oferece mensagens pub/sub integradas, valioso para adicionar reatividade em tempo real às aplicações sem polling.
O valor principal é permitir que o banco de dados empurre eventos para as sessões de aplicação ouvindo instantaneamente quando algo acontece (um novo pedido, uma mudança de status) — tipicamente combinado com triggers para que mudanças de dados notifiquem automaticamente os ouvintes, aos quais servidores de aplicação reagem (enviando para websockets, invalidando caches, disparando trabalho em background).
Isso é valioso porque fornece comportamento orientado a eventos em tempo real sem a ineficiência de fazer polling repetido no banco de dados para verificar mudanças (um padrão comum e desperdiçador que LISTEN/NOTIFY substitui elegantemente).
Compreender o mecanismo (LISTEN para se inscrever, NOTIFY para publicar, com triggers para notificação automática em mudanças de dados) e como as aplicações usam (ouvindo eventos para impulsionar reações em tempo real) é útil para construir aplicações responsivas e orientadas a eventos usando apenas PostgreSQL.
Igualmente importante é conhecer as limitações: notificações não são persistidas (perdidas se ninguém estiver ouvindo — sem garantias de durabilidade), têm pequenos payloads e só disparam após commit — então é adequado para sinalização leve em tempo real, não um substituto para um message broker durável (RabbitMQ, Kafka) quando confiabilidade e persistência importam.
Como reatividade em tempo real é uma necessidade comum e LISTEN/NOTIFY oferece uma forma integrada e sem polling de alcançá-la em casos leves, compreendê-lo — o mecanismo pub/sub, o padrão de trigger e, crucialmente, suas limitações (quando é suficiente vs quando um broker real é necessário) — é conhecimento PostgreSQL valioso e praticamente relevante para construir aplicações orientadas a eventos, um recurso integrado útil que é frequentemente negligenciado.