LISTEN и NOTIFY предоставляют встроенную систему обмена сообщениями publish/subscribe в PostgreSQL — один сеанс может отправить уведомление на канал, и другие сеансы, слушающие этот канал, получают его мгновенно. Это легкий способ отправлять события реального времени из базы данных без опроса.
LISTEN order_created;
NOTIFY order_created, ;
LISTEN подписывает на канал; NOTIFY публикует на него (с необязательной текстовой полезной нагрузкой). Слушатели получают уведомления асинхронно — опрос не требуется.
-- 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 с триггером позволяет базе данных автоматически отправлять события при изменении данных (новый заказ, обновление статуса) — серверы приложений, слушающие канал, реагируют в реальном времени.
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 — это полезная, менее известная функция PostgreSQL, которая обеспечивает встроенный pub/sub обмен сообщениями, ценная для добавления реактивности в реальном времени к приложениям без опроса.
Основная ценность заключается в том, что база данных может отправлять события слушающим сеансам приложений мгновенно, когда что-то происходит (новый заказ, изменение статуса) — обычно в сочетании с триггерами, так что изменения данных автоматически уведомляют слушателей, а серверы приложений реагируют на это (отправляя на websockets, инвалидируя кэши, запуская фоновые задачи).
Это ценно, потому что обеспечивает поведение, управляемое событиями в реальном времени, без неэффективности опроса базы данных многократно для проверки изменений (распространённый, расточительный паттерн, который LISTEN/NOTIFY элегантно заменяет).
Понимание механизма (LISTEN для подписки, NOTIFY для публикации, с триггерами для автоматического уведомления при изменении данных) и того, как приложения его используют (прослушивание событий для управления реактивными ответами в реальном времени), полезно для создания отзывчивых, управляемых событиями приложений, используя просто PostgreSQL.
Единственно важно знать ограничения: уведомления не сохраняются (теряются, если никто не слушает — нет гарантий долговечности), имеют малые полезные нагрузки и срабатывают только после commit — поэтому это подходит для лёгких сигналов реального времени, не замены надёжного брокера сообщений (RabbitMQ, Kafka), когда надёжность и сохранение важны.
Поскольку реактивность в реальном времени — это распространённая необходимость и LISTEN/NOTIFY предлагает встроенный, свободный от опроса способ достичь этого для лёгких случаев, понимание его — механизм pub/sub, паттерн с триггерами и, самое важное, его ограничения (когда он достаточен и когда нужен настоящий брокер) — это ценное, практически релевантное знание PostgreSQL для создания приложений, управляемых событиями, полезная встроенная функция, которая часто упускается из виду.