LISTEN と NOTIFY は、PostgreSQL に組み込まれた パブリッシュ/サブスクライブ メッセージングシステムを提供します。1つのセッションがチャネルに通知を送信でき、そのチャネルをリッスンしている他のセッションが即座に受け取ります。これはポーリングなしでデータベースからリアルタイムイベントをプッシュする軽量な方法です。
基本的なメカニズム
sql
LISTEN order_created;
NOTIFY order_created, ;
LISTEN と NOTIFY は、PostgreSQL に組み込まれた パブリッシュ/サブスクライブ メッセージングシステムを提供します。1つのセッションがチャネルに通知を送信でき、そのチャネルをリッスンしている他のセッションが即座に受け取ります。これはポーリングなしでデータベースからリアルタイムイベントをプッシュする軽量な方法です。
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 の有用だがあまり知られていない機能であり、組み込みパブリッシュ/サブスクライブメッセージング を提供し、ポーリングなしでアプリケーションに リアルタイム反応性 を追加するのに価値があります。
コアバリューは、何かが起きた時（新規注文、ステータス変更）にデータベースが即座にリッスンしているアプリケーションセッションにイベントを プッシュ できることです。通常は トリガー と組み合わせられるので、データ変更が自動的にリスナーに通知され、アプリケーションサーバーが反応します（WebSocket へのプッシュ、キャッシュの無効化、バックグラウンドタスクのトリガーなど）。
これは、変更がないかチェックするためにデータベースを繰り返しポーリングする非効率な一般的なパターンなしで、リアルタイムなイベント駆動型の動作を提供するため価値があります。LISTEN/NOTIFY はこのような無駄なパターンを優雅に置き換えます。
メカニズム（サブスクライブするための LISTEN、パブリッシュするための NOTIFY、データ変更時の自動通知のためのトリガー）と、アプリケーションがそれをどう使うか（イベントをリッスンしてリアルタイム反応を駆動する）の理解は、PostgreSQL だけを使って応答性の高いイベント駆動型アプリケーションを構築するのに役立ちます。
同様に重要なのは 制限事項 を知ることです。通知は 永続化されません（リッスンしている人がいなければ失われる。耐久性保証がない）、ペイロードは小さく、コミット後にのみ発火します。そのため、これは軽量なリアルタイム通知に適しており、信頼性と永続性が重要な場合は永続的メッセージブローカー（RabbitMQ、Kafka）の置き換えには適切ではありません。
リアルタイム反応性は一般的なニーズであり、LISTEN/NOTIFY は軽量な場合にポーリングなしで達成する組み込みの方法を提供するため、パブリッシュ/サブスクライブメカニズム、トリガーパターン、そして特に制限事項（どの場合に十分であるか対どの場合に実際のブローカーが必要であるか）の理解は、イベント駆動型アプリケーション構築のための実用的で関連性の高い PostgreSQL 知識であり、しばしば見落とされている有用な組み込み機能です。