Postgres LISTEN/NOTIFYは実はスケールする
原題: Postgres LISTEN/NOTIFY actually scales
なぜ重要か
PostgresをバックエンドとしたストリーミングやLLM応答配信の実用性を示し、専用インフラなしで大規模リアルタイム処理が可能になる点で業界的意義が大きい。
DBOSのPeter Kraft氏は2026年7月24日、Postgres LISTEN/NOTIFYのスケーラビリティに関する技術記事を公開した。従来は「スケールしない」と批判されてきた同機能だが、最適化によりシングルPosgresサーバーで毎秒6万回の書き込みをミリ秒単位のレイテンシで実現できることを示した。
Postgres LISTEN/NOTIFYは、過去に「スケールしない」と主張する有名なブログ記事などにより悪評を持つ機能だ。しかしDBOSのエンジニアPeter Kraft氏は、この評価は「直感に反する挙動がある」という意味であり、「スケールしない」とは同義ではないと主張している。
LISTEN/NOTIFYは、Postgresデータベースを活用して低レイテンシの耐久性ある通知・ストリーム・pub/subを実現できる強力な機能だ。基本的な設計として、ストリームテーブルを作成し、LLMのレスポンストークンなどの各チャンクを新規行として挿入する。読み取り側が次のチャンクをポーリングする方法もあるが、ポーリング間隔を短くすると同時接続数の増加でデータベースが過負荷になるという問題がある。LISTEN/NOTIFYを使えば、リーダーは通知を受け取るまでブロック待機できるため、無駄なリソース消費を抑えつつ即座に新チャンクを受け取れる。
DBOSの初期実装では、ストリームテーブルへのトリガーを使い、新チャンク書き込みのたびにNOTIFYを発火する方式を採用した。この実装は正確かつ低レイテンシを実現したものの、大規模環境では毎秒2,900回の書き込みしか維持できなかった。さらに、CPU・メモリ・IOPSなどのリソースを目立って消費しないままボトルネックが発生していた。
根本原因はPostgresがNOTIFY実行時にグローバルな排他ロックを取得する仕組みにある。NOTIFY呼び出しを含むトランザクションのコミット時にこのグローバル排他ロックが必要となる設計が、スループットを制限していた。DBOSはこの挙動を解析・最適化し、単一Postgresサーバーで毎秒6万回の書き込みとミリ秒スケールのレイテンシを達成した。記事では、この最適化の詳細な手法が技術的に解説されている。