PostgreSQL kullanan SaaS ve kurumsal uygulamalarda bağlantı sayısı, trafik arttıkça görünmez bir kapasite sınırına dönüşebilir. Her web isteğinin yeni veritabanı oturumu açması; bellek tüketimini, bağlantı kurma gecikmesini ve ani yükte hata riskini büyütür. PgBouncer gibi hafif bir connection pooler, çok sayıdaki istemci bağlantısını daha sınırlı PostgreSQL oturumları üzerinden yönetir. Ancak yanlış pool mode veya limitsiz kuyruk, sorunu çözmek yerine yalnızca başka bir katmana taşır.

PgBouncer neyi çözer, neyi çözmez?

PgBouncer uygulama ile PostgreSQL arasında durur; istemci bağlantılarını kabul eder ve uygun olduğunda gerçek veritabanı bağlantısına eşler. Böylece connection churn azalır, PostgreSQL daha öngörülebilir sayıda backend process çalıştırır ve kısa süreli trafik artışları sıraya alınabilir.

• Çözer: Sık bağlantı açma maliyeti, kontrolsüz istemci eşzamanlılığı ve bağlantı fırtınası.
• Azaltabilir: Uygulama instance sayısı arttığında PostgreSQL üzerindeki backend process baskısı.
• Çözmez: Yavaş SQL, eksik indeks, kilitlenme, yetersiz CPU/RAM/IOPS veya hatalı transaction tasarımı.

Havuzlama veritabanı kapasitesini sihirli biçimde büyütmez. Gelen işi kontrollü kuyruklar ve mevcut kapasiteyi daha verimli kullandırır. Bu nedenle bağlantı kuyruğu uzarken sorgu süresi de yükseliyorsa yalnızca pool size artırmak yerine SQL ve kaynak darboğazı araştırılmalıdır.

Pool mode seçimi: session, transaction, statement

Session pooling bir istemci bağlantısını oturum boyunca aynı PostgreSQL bağlantısına bağlar. Uygulama session state, prepared statement, geçici tablo veya bağlantı düzeyi ayarlara bağımlıysa en uyumlu moddur; fakat bağlantı yeniden kullanımı daha düşüktür.

Transaction pooling gerçek PostgreSQL bağlantısını yalnızca transaction süresince ayırır, sonra havuza döndürür. Çoğu stateless web uygulamasında yüksek verim sağlar. Buna karşılık transaction dışına taşan session state güvenli değildir. Uygulama framework’ünün prepared statement davranışı, SET kullanımı, advisory lock ve geçici tablo beklentileri test edilmelidir.

Statement pooling bağlantıyı her sorgudan sonra serbest bırakır ve çok satırlı transaction kullanımını ciddi biçimde kısıtlar. Dar kullanım alanı vardır; varsayılan seçim olarak düşünülmemelidir. Üretim kararı, yalnızca sentetik sağlık kontrolüyle değil gerçek uygulama testleriyle doğrulanmalıdır.

Bağlantı bütçesi nasıl hesaplanır?

Üç sınır birlikte ele alınmalıdır: uygulamanın açabildiği istemci bağlantısı, PgBouncer’ın kabul ettiği max_client_conn ve PostgreSQL’in max_connections değeri. Ayrıca veritabanı başına default_pool_size, yedek bağlantılar ve yönetim erişimi için ayrılan kapasite hesaba katılmalıdır.

Örneğin dört uygulama instance’ının her biri 100 bağlantı açabiliyorsa teorik istemci talebi 400’dür. Bu, PostgreSQL’e 400 backend açılması gerektiği anlamına gelmez. Ölçülen aktif transaction eşzamanlılığı 40 ise havuz bunun biraz üzerindeki güvenli kapasiteden başlayabilir. Fakat tek bir global sayı yeterli değildir: veritabanı/kullanıcı çiftleri ayrı havuzlar oluşturabilir, çoğaldıkça toplam backend bütçesi beklenenden yüksek olur.

• PostgreSQL’de yönetim, replikasyon, bakım ve failover için bağlantı rezervi bırakın.
• Uygulama tarafındaki pool ile PgBouncer pool’unu kontrolsüz biçimde üst üste bindirmeyin.
• query_wait_timeout ve uygulama timeout zincirini kullanıcı isteğinin toplam süresiyle uyumlu kurun.
• Dosya tanımlayıcı limitlerini max_client_conn ile birlikte kontrol edin.
• Kapasiteyi yalnızca ortalama trafikle değil pik ve yeniden bağlanma senaryosuyla test edin.

Güvenlik: ağ sınırı, SCRAM ve kimlik bilgileri

PgBouncer endpoint’ini internete açık genel bir servis gibi tasarlamayın. Uygulama ağı, güvenlik grubu/firewall ve yalnızca gerekli kaynaklara izin veren erişim listeleriyle sınırlandırın. İstemci ile PgBouncer, PgBouncer ile PostgreSQL arasındaki TLS gereksinimlerini ayrı ayrı değerlendirin. Sertifika doğrulamasını kapatmak şifreleme varmış gibi görünse de yanlış hedefe bağlanma riskini gidermez.

Mümkün olduğunda SCRAM tabanlı kimlik doğrulama kullanın. Kimlik bilgilerini container image, Git deposu veya düz metin deployment dosyasına gömmeyin; yetkili secret yönetimiyle dağıtın ve rotasyon runbook’u hazırlayın. Uygulama kullanıcısına superuser vermeyin. Okuma/yazma, migration ve izleme rollerini ihtiyaçlarına göre ayırın.

CVE ve sürüm yönetimi neden önemlidir?

23 Eylül 2026’da duyurulan PgBouncer 1.26.0, kimlik doğrulama öncesi istemcinin tetikleyebildiği iki hizmet reddi problemi ile kötü niyetli PostgreSQL sunucusunun tetikleyebildiği sınırsız SCRAM iş yükü problemine yönelik düzeltmeler içerdi. Ders yalnızca tek bir sürümü kurmak değildir: connection pooler, ağ trafiğini ve kimlik doğrulamayı işleyen kritik bir bileşendir; güvenlik bültenleri izlenmeli, etkilenen sürüm envanteri tutulmalı ve güncelleme test edilmelidir.

Güncellemeden önce yapılandırma uyumluluğunu, kaldırılan seçenekleri ve davranış değişikliklerini inceleyin. Bakım sırasında önce ikincil/aday instance üzerinde canary test, sonra kontrollü trafik geçişi kullanın. Online restart gibi kaldırılmış özelliklere dayanan eski runbook’ları güncelleyin. Rollback yalnızca binary geri alma değildir; config biçimi ve state beklentileri de doğrulanmalıdır.

İzlenecek metrikler ve alarm sinyalleri

PgBouncer’ın SHOW POOLS, SHOW STATS, SHOW DATABASES ve SHOW CLIENTS çıktıları bağlantı davranışını görünür kılar. Yönetim konsolunu yalnızca yetkili ağ ve rollere açın; sorgu çıktılarını merkezi metrik sistemine güvenli biçimde taşıyın.

• Bekleyen istemci sayısı ve bekleme süresi sürekli artıyor mu?
• Aktif ve boşta server bağlantıları beklenen havuz bütçesiyle uyumlu mu?
• Bağlantı kurma, transaction ve sorgu gecikmesi ayrı ayrı ölçülüyor mu?
• Timeout, auth failure ve yeniden bağlanma oranlarında ani değişim var mı?
• PostgreSQL CPU, bellek, disk gecikmesi, lock ve replication lag sinyalleriyle korelasyon kuruluyor mu?

Yalnızca “PgBouncer çalışıyor” sağlık kontrolü yeterli değildir. Havuz endpoint’i TCP kabul ederken PostgreSQL erişilemez, login kuyruğu tıkanmış veya transaction’lar bekliyor olabilir. Readiness kontrolü gerçek ama düşük maliyetli bir veritabanı doğrulamasını ve timeout bütçesini içermelidir.

Failover ve yüksek erişilebilirlikte dikkat

PostgreSQL primary değiştiğinde PgBouncer’ın eski bağlantıları ne zaman bırakacağı, DNS/service discovery’nin nasıl güncelleneceği ve uygulamanın hangi hataları tekrar deneyebileceği önceden test edilmelidir. Açık transaction’ın güvenle yeniden çalıştırılabileceğini varsaymayın; idempotency ve uygulama tarafı retry politikası gerekir. PgBouncer’ın iki instance çalışması tek başına PostgreSQL HA sağlamaz; veritabanı replikasyonu, failover ve backup/PITR ayrı katmanlardır.

Production kontrol listesi

• Pool mode gerçek uygulama davranışıyla test edildi.
• İstemci, havuz ve PostgreSQL bağlantı bütçeleri birlikte hesaplandı.
• Yönetim ve failover için rezerv bağlantı bırakıldı.
• Ağ erişimi sınırlandı; TLS ve SCRAM politikası doğrulandı.
• Kimlik bilgileri secret yönetiminde, roller en az yetkide tutuluyor.
• Bekleme, timeout, auth failure ve backend kaynakları izleniyor.
• Güvenlik bülteni, patch, canary ve rollback runbook’u mevcut.
• PostgreSQL failover tatbikatında PgBouncer ve uygulama davranışı ölçüldü.

PostgreSQL bağlantı katmanını birlikte değerlendirin

Doğru bağlantı havuzlama; uygulama profili, PostgreSQL kapasitesi, replikasyon ve geri dönüş hedefleriyle birlikte tasarlanmalıdır. Narweb’in PostgreSQL Cluster Hosting yaklaşımını inceleyebilir; mevcut bağlantı sayınızı, gecikme hedefinizi ve failover beklentinizi değerlendirmek için teknik ekiple iletişime geçebilirsiniz.