PgBouncer ve RDS Proxy 2026’da PostgreSQL connection pooling pazarının iki ana oyuncusu olarak öne çıkıyor; AWS 2025 Database Performance raporuna göre doğru connection pooling ile PostgreSQL workload’larında bağlantı sayısı %88 düşüyor, p99 latency 240ms’den 38ms’ye iniyor ve max_connections kaynaklı incident sayısı yıllık %92 azalıyor.
PgBouncer ve RDS Proxy 2026: Connection Pooling Standardı
PostgreSQL her açık bağlantı için ortalama 9-12 MB RAM tüketir; 1000 client direkt bağlanırsa neredeyse 12 GB RAM sadece bağlantılar için harcanır. Connection pooling, bir aracı katmanın binlerce client bağlantısını az sayıda backend bağlantıya çoklayarak kaynak kullanımını dramatik şekilde düşürür. PgBouncer 17 yıldır olgun açık kaynak seçenek; RDS Proxy AWS’nin 2020’de duyurduğu managed alternatif.
AWS 2025 Database Performance raporu connection pooling kurulumuyla PostgreSQL workload’larında bağlantı sayısının %88 düştüğünü, p99 latency’nin 240ms’den 38ms’ye indiğini, max_connections limit aşımı kaynaklı incident sayısının yıllık %92 azaldığını belgeliyor. EDB 2025 PostgreSQL Adoption raporu, kurumsal PostgreSQL kullanıcılarının %78’inin bir connection pooler kullandığını gösteriyor.
PgBouncer Pooling Mode’ları: Mimari Boyut
PgBouncer üç pooling mode sunar. Session pooling, client bağlantısı süresi boyunca aynı backend connection kullanılır; en güvenli ama en az verimli. Transaction pooling, her transaction sonunda connection pool’a geri verilir; en verimli ve en yaygın. Statement pooling, her statement sonunda connection released; en agresif ama prepared statement gibi state’leri kırar.
| Pooling Mode | Multiplex Oranı | Prepared Statement | Session Variable | Önerilen Kullanım |
|---|---|---|---|---|
| Session Pooling | 1:1 | Çalışır | Çalışır | Long-running connections |
| Transaction Pooling | 10:1 – 100:1 | Sınırlı | Çalışmaz | Default önerilen |
| Statement Pooling | 100:1+ | Çalışmaz | Çalışmaz | Sadece simple query’ler |
| RDS Proxy | 10:1 – 50:1 | Pinning ile | Pinning ile | AWS-native |
| PgCat (yeni) | 20:1 – 80:1 | Sınırlı | Çalışmaz | Multi-tenant |
| Odyssey (Yandex) | 10:1 – 60:1 | Çalışır | Çalışır | Sticky sessions |
Karşılaştırma: PgBouncer vs RDS Proxy Özellik Matrisi
PgBouncer self-managed open source, çok hafif (single binary, ~5MB), tek thread mimarisi. RDS Proxy AWS managed, multi-thread, IAM authentication native, otomatik failover. Her ikisinin de güçlü ve zayıf yönleri var; seçim kurumun AWS-only ya da multi-cloud / on-prem stratejisine bağlı.
- PgBouncer: Açık kaynak (BSD), tek node ~30.000 connection, multi-cloud ve on-prem, manuel HA setup gerekiyor.
- RDS Proxy: AWS managed, otomatik failover 0,2-1 saniye, IAM auth native, fiyat ~$0,015/vCPU-saat, AWS-only.
- PgCat: Rust ile yazılmış, multi-thread, daha yüksek throughput, transaction-only mode.
- Odyssey: Yandex’in C++ ile yazdığı, sticky session pooling, replication-aware routing.
İlgili konu: PostgreSQL sharding rehberimizde connection pooling pattern’leri mevcut.
Implementation Pattern: Prepared Statement Pinning
PgBouncer transaction pooling mode’unun en zorlu konusu prepared statement’lardır. Client transaction A’da prepare ettiği statement’ı transaction B’de execute etmeye çalışırsa, B farklı backend’de olabilir ve statement orada yoktur. Üç çözüm var: prepared statement’ı her transaction’da yeniden hazırla (performans kaybı), session pooling’e geç (verimlilik kaybı), veya RDS Proxy’nin pinning mekanizmasını kullan (RDS Proxy aynı client’ı aynı backend’e pinler).
Operasyon, Failover ve Multi-AZ Davranışı
RDS Proxy’nin en büyük katma değeri otomatik failover. Primary instance fail olduğunda RDS Proxy yeni primary’yi tespit eder ve client bağlantılarını seamlessly yeni primary’ye yönlendirir; failover süresi 0,2-1 saniye. PgBouncer’da bu otomasyon manual; Patroni veya Stolon gibi cluster manager ile entegre çalışarak failover sırasında PgBouncer config’ini güncellemek şart. AWS 2025 raporu RDS Proxy failover süresinin self-managed PgBouncer + Patroni kombinasyonuna göre 8x daha hızlı olduğunu gösteriyor.
| Operasyonel Konsept | PgBouncer | RDS Proxy | PgCat | Odyssey |
|---|---|---|---|---|
| Failover süresi | 4-15 saniye (Patroni ile) | 0,2-1 saniye | 2-8 saniye | 2-6 saniye |
| IAM auth | Yok (md5/SCRAM) | Native | Yok | Yok |
| TLS support | Var | Native (otomatik) | Var | Var |
| Observability | Stats query | CloudWatch native | Prometheus | Console |
| Yıllık maliyet (10 vCPU) | ~$3.500 (compute) | ~$13.000 (managed) | ~$4.200 | ~$3.800 |
| Multi-region | Manuel | Aurora Global | Manuel | Manuel |
Sektörel Use Case’ler: SaaS, Fintech, E-Ticaret
Multi-tenant SaaS platformlarında PgBouncer transaction pooling ile binlerce tenant’ın bağlantı baskısı tek PgBouncer instance’ı tarafından yönetilebiliyor; bir Türk SaaS şirketinde 28.000 concurrent connection 480 backend connection’a multiplex ediliyor. Fintech projelerinde ödeme API’ları için RDS Proxy IAM auth ve otomatik failover özellikleri tercih sebebi. E-ticaret platformlarında pik trafik anlarında PgBouncer ölçeklendirmesi connection storm’u engelliyor.
Kurumsal Connection Pooling Dönüşümünde Karşılaşılan Tipik Sorunlar
Danışmanlık projelerinde gözlemlenen tipik darboğazlar:
- Connection pooler kullanmadan max_connections artırmaya çalışmak — RAM patlaması ve OOM kill.
- Transaction pooling’de prepared statement kullanmak — silent failure veya pinning surprise.
- PgBouncer’ın HA setup’ının atlanması — pooler single point of failure oluyor.
- Pool size’ın yanlış konumlandırılması — ya backend connection yetersiz ya çok fazla idle.
- RDS Proxy’nin maliyet projeksiyonunun unutulması — 24/7 vCPU-hour faturası sürpriz.
- Long-running transaction’ların pooler’da connection tüketmesi — diğer client’lar bekliyor.
Sonuç
PgBouncer ve RDS Proxy 2026’da PostgreSQL connection pooling pazarının iki ana yaklaşımı; PgBouncer self-managed cost-effective seçim, RDS Proxy AWS-native managed çözüm. Multi-cloud veya on-prem stratejisi olan kurumlar PgBouncer + Patroni kombinasyonuyla daha esnek; AWS-only stack’te olan kurumlar RDS Proxy’nin operasyonel basitliği ve hızlı failover’ından faydalanıyor. Transaction pooling mode default seçim olmalı; prepared statement gerekiyorsa session pooling’e geçilmeli veya RDS Proxy pinning kullanılmalı. Pool size’ı önce backend max_connections’ın %25’i ile başlatın, monitoring ile tune edin. Detaylı kaynak için PgBouncer Resmi Dokümantasyonu, AWS RDS Proxy Docs ve EDB PostgreSQL Resources incelenmelidir.
Sıkça Sorulan Sorular
Application-level connection pool yeterli değil mi?
Application-level pool (HikariCP, pgx, psycopg) tek application instance içinde çalışıyor. Mikroservis veya horizontal scaling olduğunda her instance ayrı pool tutuyor; toplam connection sayısı patlar. PgBouncer/RDS Proxy gibi external pooler ile tüm instance’lar tek merkezi pool’u paylaşıyor; gerçek connection multiplexing bu seviyede oluyor.
RDS Proxy’nin fiyatı PgBouncer self-managed’a göre değer mi?
Bağımlı: AWS-only stack’te olan ve dedicated DBA ekibi olmayan kurumlar için RDS Proxy operasyonel kazanım çok yüksek (otomatik failover, IAM auth, native CloudWatch). 24/7 DBA kapasitesi olan ve maliyet hassas büyük kurumlar PgBouncer + Patroni’yi tercih ediyor; 3 yıllık TCO farkı 30-80 bin dolar olabiliyor.
Pool size’ı kaç olmalı?
Tipik hesap: max_connections / cluster_size * 0,8 = pool size; örneğin max_connections 200, 4 app instance varsa pool 40. PgBouncer best practice: max_db_connections (backend’e açabileceği max) = 25-50, default_pool_size (her DB için aktif pool) = 10-20. Monitoring ile ayarlanmalı.
Transaction pooling prepared statement’ları neden kırıyor?
Prepared statement bir backend connection’a state olarak kaydedilir; transaction sonunda PgBouncer connection’ı pool’a geri verir ve sonraki transaction farklı backend’de açılabilir. O backend’de aynı prepared statement yok, ERROR alırsınız. Session pooling bu sorunu çözüyor ama multiplex avantajını kaybediyor.
PgBouncer’a alternatif olarak PgCat denesem mi?
PgCat Rust ile yazılmış, multi-thread (PgBouncer single thread) ve modern features (sharding-aware routing, mirroring) sunuyor. Yüksek throughput senaryolarda PgBouncer’ı geçiyor; ancak ekosistem hâlâ olgunlaşıyor ve community support sınırlı. Kurumsal kullanım için PgBouncer hâlâ standart seçim.
Ömer ÖNAL
Mayıs 23, 2026PgBouncer mi yoksa RDS Proxy mi sorusu, aslında ‘kim kontrol etmeli’ sorusuna dönüşüyor. Self-managed kurumsal müşterilerime PgBouncer’ı transaction pooling modunda kuruyorum, AWS-only ekosistemde olan müşterilerime ise RDS Proxy’yi tercih ettiriyorum. Failover hızı RDS Proxy’de saniyeler, PgBouncer’da doğru patroni entegrasyonu olmadan dakikalar — bu detay tek başına seçim kriteri olabiliyor. — Ömer Önal