PgBouncer'da Session/Transaction/Statement modlarından hangisini seçmeliyim?

Kısa cevap: Web/mikroservis filosu için Transaction modu — bağlantı yeniden kullanımını en yükseğe çıkaran tek seçenek bu.

Yaşadığın şey net: 50 pod × min bağlantı, max_connections’ı tüketiyor. PgBouncer tam da bunu çözer — çok sayıda client bağlantısını az sayıda sunucu bağlantısına multiplexler, yani max_connections’ı şişirmeden RAM’i kurtarırsın.

1. Transaction modu en yüksek yeniden kullanımı verir. Sunucu bağlantısını her transaction sonunda havuza iade eder; iki ardışık transaction farklı sunucu bağlantısına düşebilir. Yüzlerce kısa-ömürlü mikroservis isteği için doğru mod budur, çünkü bağlantı boşta beklemez.
2. Session modu avantajı çöpe atar. Her client’a tüm oturumu boyunca bir sunucu bağlantısı bağlar — yani gerçekte 50 pod yine 50+ sunucu bağlantısı tutar, multiplexing kazancı kaybolur. Sadece session state’e gerçekten muhtaçsan mantıklı.
3. Statement modu fazla kısıtlayıcı. Bağlantıyı her statement sonunda iade eder, bu da çok statement’lı transaction’ları bozar. Pratikte web uygulaması için kullanılmaz; sadece tek-statement, autocommit dünyalarda iş görür.
4. Asıl tuzak: Transaction modu prepared statement ve session state’i bozar. Protokol seviyesi prepared statement’lar, SET, advisory lock ve LISTEN gibi bağlantıya bağlı durumlar farklı sunucu bağlantısına düşünce kaybolur. Çözüm: client-side prepared statement’ları kapat (örn. PDO ATTR_EMULATE_PREPARES) ya da PgBouncer 1.21+ prepared-statement desteğini aç; ve hiçbir zaman statement’lar arası session state’e güvenme.
5. default_pool_size’ı makul tut. Sunucu bağlantısı havuzunu kocaman yapma — multiplexing’in tüm anlamı az sunucu bağlantısıyla çok client’a hizmet etmek. Önce gerçek eşzamanlılığını ölç, havuzu ona göre boyutla.

Sonuç: Ben olsam Transaction modu seçer, uygulamada server-side/protokol prepared statement’ları kapatır (ya da PgBouncer’ı 1.21+‘a yükseltirim) ve default_pool_size’ı ölçülmüş eşzamanlılığa göre dar tutardım. Session modu sorununu çözmez, Statement modu uygulamanı kırar. Bu arada, dikeyde max_connections ve RAM’i katlamak yerine bağlantı havuzlamayı çözmek çoğu zaman tam da PostgreSQL’i “yeterli” kılan hamledir — bu tartışmanın derinine sade.dev’deki yazıda girdim.