なぜ私たちは「また」Postgresのコネクションプーラーを作ったのか？

Postgresのコネクション管理にお悩みですか？世の中には既にいくつものプーラーが存在しますが、私たちはあえてゼロから新しいソリューションを開発しました。なぜ既存の選択肢では不十分だったのか、私たちが解決したかった真の課題と、新しいプーラーの設計思想について詳しく解説します。

数日前にDjangoアプリをPgBouncerのトランザクションプーリング環境へ移行したんだけど、驚かされたのはSETコマンドよりもむしろqueryset.iterator()だったよ。これってサーバーサイドカーソルに依存してるんだけど、プーリングを挟むと生き残れないんだよね。だから全箇所で無効化してクライアントサイドの処理に戻さざるを得なかった。あと、statement_timeoutもアプリの接続オプションからではなく、プーラー側の接続クエリとして設定し直す必要があった。libpqの起動パラメータはプーラー越しだと黙って無視されちゃうからね。

コネクションプーラーはクライアント間で接続を再利用するから、あるクライアントの接続状態が別のクライアントに“漏洩”してしまう。

うわ、これ相当ヤバいね。Postgresの典型的なセットアップでも実際にこんなことが起きるの？

ClickhouseもPgBouncerのスケーリングに関する面白い記事を出してるよ。shardingを厳しくしすぎずにso_reuseportを使ってスケールアウトさせるっていう話で（pgdogがリライトで対処している主要な制限の一つだね）。
https://clickhouse.com/blog/pgbouncer-clickhouse-managed-pos... (https://clickhouse.com/blog/pgbouncer-clickhouse-managed-postgres) https://news.ycombinator.com/item?id=48814152 (https://news.ycombinator.com/item?id=48814152)

NOTIFYのパフォーマンス修正ってことは、もうトランザクション的ではなくなったってことじゃないの？

Selectに対するクエリキャッシュを追加する予定はある？

ここの内容みたいにね：

https://www.pgpool.net/docs/latest/en/html/runtime-in-memory... (https://www.pgpool.net/docs/latest/en/html/runtime-in-memory-query-cache.html)

PostgreSQLでスキーマ切り替えに対応したプーラーってどこかにあるかな？django-tenantの前に置けるようなやつ。

最近よくあるひどいBSL系ライセンスじゃなくて、AGPLを採用してくれたのは最高だね。