PgBouncer なしで Postgres を運用している人はいますか？

brandur.org 記事 アトム フラグメント ニュースレター シーケンス 現在利用中 その他 Auto PgBouncer なしで Postgres を運用している人はいますか？ フラグメント 🔗 PgBouncer なしで Postgres を運用している人はいますか？ 公開日 2026年8月12日 X/Twitter は @brandur です。 2026年8月12日 先週末、データベース接続の管理に関する私の古い記事が Ben Dicken から素晴らしい紹介を受けました。（この人はデータベース界のミック・ジャガーのようで、一日でこんなに多くの LinkedIn の招待を受け取ったのは初めてです。）驚いたのは、この記事を書いてからもう10年近く経つことです。さらに驚くべきは、読み返してみると、10年前の記事であるにもかかわらず、ほとんどそのまま通用することです。Postgres は、多くの接続を管理するのが得意とは言えません。そのため、ローカルコネクションプール、短期チェックアウト、そして PgBouncer のようなプーラーを使用することが推奨されます。そこで疑問に思ったのは、プーラーの使用はどの程度標準的なのかということです。その疑問に答えるため、有名なマネージド Postgres プロバイダーをいくつかリストアップし、PgBouncer、それに近いもの、あるいは全くコネクションプーリングをサポートしていないかどうかをまとめた表を作成しました。 プロバイダー | プーラー？ | 実装 | 利用可能性 / 注意点 ---|---|---|--- Aiven | ✅ | PgBouncer | スタートアッププラン以上 Alibaba RDS | ✅ | PgBouncer | AWS RDS / Aurora | ✅ | RDS Proxy | 別のマネージドプロキシサービス Azure PG | ✅ | PgBouncer | Crunchy Bridge | ✅ | PgBouncer | DigitalOcean | ✅ | PgBouncer | EDB Postgres AI | ✅ | PgBouncer | Fly.io MPG | ✅ | PgBouncer | Google Cloud SQL | ✅ | PgBouncer / マネージドプーリング | エンタープライズプラスが必要 Heroku | ✅ | PgBouncer | 一部のプランのみ IBM Cloud | ❌ | — | セルフマネージドのみ Neon | ✅ | PgBouncer | OCI (Oracle) | ❌ | — | マネージドプーラーなし PlanetScale | ✅ | PgBouncer | Railway | ✅ | PgBouncer | 別サービスとして追加 Render | ✅ | PgBouncer | 有料データベースの場合 Supabase | ✅ | PgBouncer または Supavisor | サーバーレスの場合 PgBouncer または Supavisor（独自プーラー） Tiger Cloud | ✅ | PgBouncer | PgBouncer のサポートが広く普及しているだけでなく、上記の表からわかるように、ほとんどのプロバイダーが標準でバンドルしています。さらに一歩進んで言えば、IBM や Oracle のような、エンタープライズセールスサイクルの一部でない限り、まともな人は使わないようなサービスを除けば、現実的なマネージド Postgres プロバイダーの 100% がプーラーをバンドルしています。もし皆が必要としているなら、それは本当にコア機能ではないと言えるのでしょうか？ ある意味では、この現状は許容できると主張することもできます。コネクションプーラーを必要とするユーザーは、それを利用でき、本番環境を安定させるために使用できます。しかし、明らかに多くの労力が無駄になっています。すべてのプロバイダーは、複数のコンポーネントを設定・構成するための独自の仕組みを開発し、Postgres とそのバウンサーの場所に関する規約を確立しなければなりませんでした。すべてのユーザーは、PgBouncer の制限（例: listen/notify を使用しない）を説明するガイドを参照し、そのプーリングモードとトレードオフについて読む必要があります。地元の自動車ディーラーに行って、フロントガラスのない車を売られたと想像してみてください。そこへ行く途中で、路上を走っている車の 100% にフロントガラスが付いていることに気づき、それにはもっともな理由があることがわかったでしょう。フロントガラスなしで運転するのは非常に危険だからです。車を買ったあなたが、運転可能な状態にする前にフロントガラスを取り付ける責任があると言うのは難しいですが、すぐに運転できない車を売ったディーラーに対して後で腹を立てるのはもっともなことです。 再統合 お気に入りの Postgres プロバイダーに行って、追加の設定や注意点なしに、単一のデータベース URL とポートで済む世界があったらどうでしょうか？ マネージドプロバイダーは、後付けのフロントガラスを追加する必要がなく、車に最初から付いているようなものです。このような場所が存在することは、MySQL や Mongo の世界ではすでに実現していることなのでわかっています。それには理由があります。例えば、長年議論されているプロセス対スレッドの議論を再燃させ、進歩を推進するにはごく少数の貢献者しか認められていない、といったことです。しかし、Postgres のコネクションプーリングの欠点を回避するために費やされた開発者年数を考えると、これが最も影響力の大きい運用改善の 1 つであることは間違いないでしょう。間違いを見つけましたか？ プルリクエストの送信を検討してください。