PgDog：アプリを書き換えずに済むPostgresコネクションプーラー

PgDogはコネクションプーリングを行うPostgresプロキシですが、PgBouncer、RDS Proxy、Pgpool-IIとは異なり、コアなPostgres機能を犠牲にする必要はありません。開発チームは、既存のプーラーが漏れやすい抽象化をもたらし、スケール時にアプリケーションコードの変更を強制すると主張しています。PgDogはそれを修正することを目指しています。

漏れのないセッション状態

従来のプーラーはクライアント間で接続を再利用するため、SETコマンドのようなセッションレベルの状態がクライアント間で漏れます。これは、行レベルセキュリティ（RLS）やクエリタイムアウトにSETを依存している場合に問題です。PgDogは、組み込みのSQLパーサーでSET文を解析し、状態をクライアントごとに保存し、各クエリの前に復元することでこれを解決します。クエリパイプラインを使用して複数のSET復元を1回のラウンドトリップにまとめ、パフォーマンスへの影響を最小限に抑えます。

プーリングで実際に動作するLISTEN/NOTIFY

LISTENとNOTIFYは、トランザクションモードの従来のプーラーのもう1つの犠牲者です。PgDogはこれらを内部で処理します。同じプロセス内のクライアント間でメッセージを移動するためにTokioのbroadcastチャネルを使用し、複数のPgDogプロセス間で同期するために専用のPostgres接続を使用します。その結果、pub/subセマンティクスが透過的に機能し、トランザクションの保証が維持されます。

デフォルトでマルチスレッド

Tokio上に構築されたPgDogは、マルチスレッドワーカーで非同期Rustを使用します。各クライアントは独自の非同期タスクを取得し、接続数に応じて線形にスケールします。これにより、PgBouncerのシャーディング問題（SO_REUSEPORTとプロセスごとの接続プールが必要）や、オートスケーリングプロキシのコールドスタートレイテンシを回避します。単一のPgDogプロセスでより多くのクライアントとクエリを処理できるため、運用が簡素化されます（1つのメトリクスエンドポイント、1つのヘルスチェック、カーネルレベルのトリックは不要）。

本番環境で実証済み

PgDogは1年以上本番環境で使用され、毎秒200万クエリの接続をプールしています。オープンソース（MIT）で、どこにでもデプロイ可能です。SETやLISTEN/NOTIFYを諦められないためにコネクションプーリングを避けてきたなら、これが待ち望んだプーラーかもしれません。