注目★★★★★Hacker News
PostgreSQL の LISTEN/NOTIFY は実はスケールする、60K writes/秒を実証
30秒で把握
- 1PostgreSQL LISTEN/NOTIFY のスケール限界（従来 2.9K writes/秒）はトランザクションコミット時の大域排他ロックが原因と解析・実証
- 2バッファリング＋バッチフラッシュで大域ロック頻度を削減、60K writes/秒達成・20倍性能向上
- 3フォールバック読み取り（低頻度ポーリング）で未配信通知をカバー・本番運用可能な実装パターン確立
要約
PostgreSQL の LISTEN/NOTIFY はスケールしないという評判は根拠に基づかないと DBOS が実証した。LISTEN/NOTIFY はトランザクションコミット時に取得される大域排他ロックがボトルネックになるが、バッファリング + バッチ処理で回避できると論じた。ストリーム書き込みを記憶中にバッファして定期的にまとめて送信することで、大域ロックの取得頻度を削減し、グループコミット最適化を活用可能にした。その結果、単一 PostgreSQL サーバで 60K writes/秒 (従来の 20 倍) とミリ秒単位遅延を同時達成し、CPU が飽和する本来の性能限界に到達したことを確認した。
あなたへの影響
PostgreSQL で durable pub/sub やストリーム機構を検討するチームは、LISTEN/NOTIFY の真の制限を正しく理解して設計判断できる。
推奨：バッファリング + フォールバック読み取りの組み合わせは、アプリケーション層で実装する最小限の工夫で高スループットを得られるため、次のシステム設計時に採用価値を評価する価値がある。