PostgresにPgBouncerなしで挑む人はいるのか？主要マネージドDBプロバイダーの実態調査
Does anyone run Postgres without PgBouncer?
著者が10年前に書いたPostgresの接続管理に関する記事が、今もなお有効であることに驚きつつ、PgBouncerなどのコネクションプーラーの利用がどれほど標準的かを調査した。主要なマネージドPostgresプロバイダー17社のうち、IBM CloudとOCIを除くすべてがPgBouncerまたは類似のプーラーを提供している。この現状は「車にフロントガラスなしで販売するようなもの」と著者は批判し、Postgres本体にプーリング機能が組み込まれるべきだと主張する。
車を買うときにフロントガラスが付いていない車を売られたら、後でディーラーに怒るのは当然だろう。
HNでの議論
108- conradludgate
(私はNeonでPostgresプロキシレイヤーを担当しています)
PgBouncerは完全に任意であり、常に正しい選択とは限りません。古典的なアプリ（サーバーレスではない）で、アプリから接続プールを維持できるのであれば、PgBouncerを避けることをお勧めします。
PgBouncerの利点は、主に不規則なクライアント接続（多すぎる、チャーンが多すぎる）から得られます。そのような問題がなければ、Postgresに直接接続してください。
現在、PgBouncerを代替（おそらく自社製）に置き換えることを検討しています。主にマルチテナンシーとHAの理由からです。PgBouncerは私たちにとって良いものでしたが、マルチテナント環境での展開方法に制限があります。
- petcat
この質問は、「非自明なワークロードでPgBouncerなしでPostgresを実行している人はいますか？」と限定されれば、より興味深い回答が得られるでしょう。
なぜなら、これまでのコメントからもわかるように、月に10ヒットしかないブログには必要ないと言う人がたくさんいるからです。
個人的には、適度に同時実行性のあるワークロードでPgBouncerや何らかの接続プーリングプロキシを使わない人を聞いたことがありません。Postgresのプロセス・パー・コネクションアーキテクチャは、ほぼそれを要求します。そうでなければ、小さな接続ストームでもサーバーに大損害を与えるでしょう。
- solatic
記事のタイトルは完全にクリックベイトです。PgBouncerは複雑さを追加します。必要なら使えばいいし、必要でなければ、複雑さを無駄に追加しただけです。
> IBMもOracleも、エンタープライズのセールスサイクルに関わっていない自尊心のある人なら誰も実際に使わないサービスである
著者は深刻なエゴチェックが必要です。IBM Cloudを選ぶ正当な工学的理由（Zメインフレームをサポートする必要がある場合など。エンタープライズ系の人々に販売するなら時々必要になります）や、Oracle Cloud（他のクラウドプロバイダーがサービスを提供していない都市にデータセンターを建設し、最低遅延を提供できる）を選ぶ理由があります。これらの理由は一般的ではないかもしれませんが、確かに正当です。
- matsemann
Python: アプリが成長すると、プロセス数とさまざまなデプロイメントが多いため、絶対に必要です。
Java: かなり大きなアプリでも必要性を感じたことはありません。ローカルで接続プールを共有するのがはるかに簡単なので、アプリ全体で単一接続がそれほど多くありません。
- giovannibonetti
多くのコメントがPgBouncerとアプリケーション接続プーラーを比較していますが、それらの概念的な違いには触れていません。ここにそれを示します：
1. ほとんどのアプリケーション接続プーラーは先入れ先出し（FIFO）アルゴリズムに従います。これは実装が簡単で、アプリケーションが常にデータベースに接続できることを保証するのに十分です。低遅延を最適化し、アプリケーションの観点からは素晴らしく機能します。問題は、冗長な接続を削除するメカニズムがほとんどないことです。アプリケーションが常にそれらを「ウォーム」に保っているからです。
2. PgBouncerと非常に少数の外部プーラーは逆の考え方、後入れ先出し（LIFO）に従い、Postgresに到達する接続数を減らすことを最適化し、スループットを向上させます。この考え方は最初はクレイジーに見えるかもしれませんが（最後に使用された接続が最初に再利用される）、このアルゴリズムは自動的に余分な接続を削除し、それらはコールドになり閉じられます。
新しいアプリケーションを開始するときは、オプション(1)で十分ですが、十分にスケールアップすると、いつかはオプション(2)を使用することをお勧めします。なぜなら、Postgresへの数百のオープン接続は、PgBouncerなどで90%削減できる場合、パフォーマンスに悪影響を与えるからです。Postgresのプロセス・パー・コネクション設計は、到達する接続が少ないほどはるかにうまく機能します。
- fabian2k
アプリケーションに接続プーラーがあり、データベースがそのアプリケーションだけに使用されている場合、PgBouncerのような外部プールは必要ありません。これはおそらくかなり一般的なシナリオであり、典型的なWebフレームワークには接続プールが含まれています。
追加の複雑さとして、より積極的なプーリング方法には副作用があり、アプリケーションでそれを認識して防ぐ必要があります。それらはそのまま安全に使用できるわけではありません。
接続プールの必要性は、重いプロセスベースのPostgreSQL接続の副作用です。そして、遠くない将来のある時点でこれが変わり、ユーザーがこの部分についてあまり考えなくて済むようになるだろうと推測します。
- mbreese
これは正しい質問ではないと思います。明らかにPgBouncerなしでPostgresを使用する人々はいます。非本番環境（CI/CD）を含めると、ほとんどの接続はそれを避けるでしょう。
しかし、PgBouncerが非常に一般的であるため、質問はおそらく「なぜ接続プーリングはPostgresに標準で組み込まれていないのか？」であるべきです。これがより興味深い質問だと思います。
- theandrewbailey
はい。時々、PostgreSQLは低トラフィックでシンプルなアプリケーションには過剰です。PgBouncerはさらに過剰で、不要な複雑さを追加するでしょう。