PostgreSQL Connection Pooling: PgBouncer, PgCat ve Üretim 2026

PgBouncer nedir? PgBouncer, PostgreSQL önünde duran hafif (tek thread, libevent tabanlı, yaklaşık 2 MB RAM tüketen) bir connection pooler’dır; uygulama tarafındaki binlerce kısa ömürlü bağlantıyı, veritabanı tarafında onlarca uzun ömürlü “server bağlantısına” çoklar. PostgreSQL’in her bağlantıyı ayrı bir OS process’i olarak açtığı ve her bağlantının ortalama 8-12 MB RAM tükettiği gerçeği düşünüldüğünde, pooler kullanmamak 2026 üretim ortamında bir tercih değil, ihmal. Bu yazıda PgBouncer’ın transaction/session/statement modlarını, PgCat’in (Rust ile yazılmış multi-threaded modern alternatif) sharding ve load balancing yeteneklerini, Supabase Supavisor ve AWS RDS Proxy gibi managed çözümleri gerçek rakamlarla karşılaştırıyorum; üretimde işe yarayan konfigürasyon eşiklerini, gözlemlenebilirlik komutlarını ve sık yapılan üç ölümcül hatayı anlatıyorum.

PostgreSQL Wiki’nin “Number of Database Connections” makalesinde sabitlenen pratik kural hâlâ geçerlidir: connections = ((core_count * 2) + effective_spindle_count). 16 vCPU’lu modern bir RDS db.m6i.4xlarge instance için bu yaklaşık 35-40 fiziksel bağlantı eder; uygulama tarafında ise 500-2000 client bağlantısı görmek olağandır. PgBouncer 1.23 (Kasım 2024) ve PgCat 1.2 (2025) ile bu uçurum production-grade kapatılır.

Neden Connection Pooling Bir Tercih Değil

PostgreSQL, MySQL’in aksine bağlantı başına thread değil, bağlantı başına process kullanır (fork modeli). Brandur Leach’in pgBouncer benchmark yazısında ve Citus Data’nın “Performance Impact of Idle PostgreSQL Connections” çalışmasında ölçülen gerçek: idle bir PostgreSQL bağlantısı bile bağlam değiştirme (context switch), snapshot tutma ve ProcArrayLock üzerindeki spin maliyeti nedeniyle aktif sorguları yavaşlatır. 1000 idle bağlantı, ortalama TPS’i %20-30 düşürebilir; 10 binlik idle bağlantı havuzu instance’ı tamamen kilitleyebilir.

2024 Stack Overflow Developer Survey‘e göre profesyonel geliştiricilerin %49’u PostgreSQL kullanıyor (en çok tercih edilen DB). Bu yaygınlığa rağmen, üretim incident’lerinin önemli bölümü “too many connections” hatasından kaynaklanıyor — çünkü çoğu ekip max_connections‘ı arttırarak “çözüyor”, oysa doğru çözüm pooler.

• Sorun: Her PostgreSQL bağlantısı 8-12 MB RAM + fork overhead’i tüketir.
• Etki: 500 bağlantı ≈ 5-6 GB salt bağlantı RAM’i, üstüne work_mem ve shared_buffers.
• Çözüm: Pooler ile client:server oranı 50:1 ila 200:1 arasına çekilir.
• Ne zaman seç: Uygulama bağlantı sayısı 100’ü aşıyorsa veya serverless/Lambda kullanıyorsanız zorunlu.

Pooler	Dil	Mimari	Sürüm (2026)	RAM	Maks. backend	Lisans
PgBouncer	C	Tek thread, libevent	1.23.x	~2 MB + bağlantı başına 2 KB	~10.000 client	ISC
PgCat	Rust (Tokio)	Multi-thread, async	1.2.x	~20-40 MB	~25.000+ (multi-core)	MIT
Odyssey	C	Multi-thread, coroutine	1.4	~10 MB	~15.000	BSD
Supavisor	Elixir/OTP	BEAM VM, dağıtık	1.x	~100 MB+	1.000.000+ (cluster)	Apache-2.0
RDS Proxy	Kapalı kaynak	AWS managed	—	—	Instance class’a bağlı	Ticari
pgpool-II	C	Multi-process	4.5.x	~5 MB/proc	~5.000	BSD-like

PgBouncer: Endüstri Standardı ve Üç Pooling Modu

PgBouncer 2007’den beri pratikte PostgreSQL pooling’in de facto standardıdır. GitHub’da yaklaşık 3.000+ yıldız, Debian/Ubuntu/RHEL resmi repolarında mevcut. Tek bir process, libevent ile binlerce eşzamanlı bağlantıyı yönetir; çünkü her bağlantı bir thread değil, bir non-blocking file descriptor’dur. PgBouncer’ın gücü sadelikten gelir: 25 KB civarında binary, INI tabanlı config, SQL benzeri admin konsolu.

Üç pooling modu vardır ve doğru modu seçmek üretimdeki en kritik karardır:

1. Session pooling (varsayılan): Client bağlantı kapatana dek server bağlantısı bağlı kalır. Avantaj: Tüm PostgreSQL özellikleri çalışır (prepared statements, SET, LISTEN/NOTIFY, advisory lock). Dezavantaj: Multiplexing kazancı az. Ne zaman seç: Long-running uygulamalar, ORM’ler, session state’e ihtiyaç olduğunda.
2. Transaction pooling (üretimde en yaygın): Server bağlantısı her transaction sonunda havuza döner. Avantaj: 100:1 multiplexing oranı kolay. Dezavantaj: Session-level özellikler (named prepared statements, SET LOCAL hariç SET, advisory lock, cursor with hold) çalışmaz. Ne zaman seç: Web/API uygulamaları, kısa transaction’lar.
3. Statement pooling: Her statement sonunda dönüş. Avantaj: Maksimum multiplexing. Dezavantaj: Multi-statement transaction yasak. Ne zaman seç: Sadece autocommit read-only iş yükleri (analitik dashboard’lar).

PgBouncer 1.21’den itibaren protocol-level prepared statement support eklendi (max_prepared_statements parametresi). Bu, transaction modunda bile prepared statement’ları çalıştırmayı mümkün kıldı; resmi changelog‘a göre bu özellik PostgreSQL 14+ ile uyumlu.

Özellik	Session	Transaction	Statement
SET / SET LOCAL	İkisi de	Yalnız SET LOCAL	Yalnız tek statement
LISTEN / NOTIFY	Çalışır	Çalışmaz	Çalışmaz
Advisory lock (session)	Çalışır	Çalışmaz	Çalışmaz
Prepared stmts (named)	Çalışır	1.21+ ile çalışır	Çalışmaz
Cursor WITH HOLD	Çalışır	Çalışmaz	Çalışmaz
Tipik multiplexing	1-5x	50-200x	500x+
Üretimde önerilen	Legacy/ORM	Evet (varsayılan)	Niş

Üretim PgBouncer Konfigürasyonu (Gerçek Eşikler)

PgBouncer’ın pgbouncer.ini dosyası 100+ parametre kabul eder; üretimde önemli olanlar bir avuçtur. Aşağıdaki şablon, 16 vCPU’lu Postgres + 4 vCPU PgBouncer host’u için makul başlangıçtır:

[databases]
prod = host=10.0.1.10 port=5432 dbname=app pool_size=25

[pgbouncer]
listen_port = 6432
listen_addr = 0.0.0.0
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 5000
default_pool_size = 25
reserve_pool_size = 5
reserve_pool_timeout = 3
server_idle_timeout = 600
server_lifetime = 3600
query_wait_timeout = 120
max_prepared_statements = 200
admin_users = pgbouncer_admin
stats_users = pgbouncer_stats

• pool_size: Backend PostgreSQL’in max_connections‘ının (her pooler’a düşen) %70-80’i. 100’ü aşmaktan kaçının; CPU başına 2-3 bağlantı altın oran.
• max_client_conn: Uygulamadan beklenen tepe bağlantı sayısı + %30 tampon.
• reserve_pool_size: Trafik spike’larında devreye giren ekstra havuz; reserve_pool_timeout saniyesi sonra açılır.
• server_lifetime: Uzun ömürlü bağlantıları periyodik geri dönüştürür (TLS sertifika rotasyonu ve DNS yenilenmesi için kritik).
• query_wait_timeout: Client’ın havuzdan bağlantı bekleme süresi; bu sürede uygulama “server login has been failing” değil, kuyrukta beklediğini öğrenir.

Operasyonel gözlem için PgBouncer’ın admin konsoluna psql -p 6432 -U pgbouncer pgbouncer ile bağlanılır ve şu komutlar üretimde günlük rutindir: SHOW POOLS; (her havuzun cl_active, cl_waiting, sv_active, sv_idle metrikleri), SHOW STATS; (sorgu hızı, transaction sayısı), SHOW CLIENTS; (anlık client durumu), RELOAD; (konfig yeniden yükleme, çoğu parametre için yeniden başlatma gerekmez). Prometheus için resmi pgbouncer_exporter bu metrikleri scrape eder.

PgCat: Rust ile Yeni Nesil Pooler

PgCat, eski Instacart altyapı ekibinden Lev Kokotov ve ekibinin başlattığı, Rust + Tokio üzerine kurulu açık kaynak (MIT) bir pooler. GitHub’da yaklaşık 4.500+ yıldız (2026 başı), Postgres.ai ve PostgresML tarafından prodüksiyonda kullanılıyor. PgBouncer’ın tek thread mimarisinin aksine PgCat, worker_threads ile tüm CPU çekirdeklerini kullanır; 16 vCPU host’ta yaklaşık 4-6 kat daha fazla TPS işleyebildiği topluluk benchmark’larında raporlanıyor.

PgCat’in PgBouncer’a göre öne çıkan özellikleri:

• Yatay sharding: Native sharding desteği; sharding function olarak pg_bigint_hash veya custom Lua. Citus eklentisine ihtiyaç duymadan uygulama-katmanı sharding.
• Load balancing: Replica’lar arasında round-robin veya random; replica lag’ine göre yönlendirme (banlist).
• Read/Write split: SELECT’leri otomatik replica’ya yönlendirme (deneysel, uygulamada query hint öneriliyor).
• Failover: Primary erişilemediğinde admin DB üzerinden yeni primary’yi promote eden hook.
• Mirroring: Üretim trafiğini staging’e yansıtma (regression test için).
• SCRAM-SHA-256 + TLS: PgBouncer ile feature parity.

Boyut	PgBouncer 1.23	PgCat 1.2	Pratik fark
Thread modeli	Tek thread	Tokio multi-thread	PgCat: çekirdek sayısına lineer ölçeklenir
Sharding	Yok	Native	PgCat: uygulama-katmanı sharding gerekmez
Read/Write split	Yok	Var	PgCat: replica trafiği otomatik
Prepared statements	1.21+ (transaction)	Var	İkisi de
Olgunluk	17+ yıl	~3 yıl	PgBouncer: daha az “edge case” sürprizi
Olağan tepe TPS (16 vCPU)	~80-100k	~250-400k	Benchmark, topluluk
Config formatı	INI	TOML	PgCat: hot-reload daha güvenli

Karar çerçevesi: Avantaj (PgCat): tek host’tan yüksek throughput, sharding lazımsa biçilmiş kaftan. Dezavantaj (PgCat): ekosistem henüz dar, debugging için topluluk küçük. Ne zaman seç: 100k+ TPS gereken, sharding/load-balancing yapan ekipler. Aksi halde: PgBouncer’ın 17 yıllık üretim olgunluğunu tercih edin.

Managed Çözümler: Supavisor, RDS Proxy, Cloud SQL Auth Proxy

Self-hosted pooler işletmek istemeyen ekipler için cloud sağlayıcıları kendi çözümlerini sunuyor. Üçü ciddi alternatif:

Supabase Supavisor (Elixir/OTP, BEAM VM tabanlı): Multi-tenant olarak tasarlandı, milyon mertebesinde eşzamanlı bağlantı hedefliyor. GitHub deposu‘na göre Supabase 2024’te kendi platformunda PgBouncer’ı Supavisor ile değiştirdi. Pratikte serverless/edge fonksiyonlardan gelen 100K+ kısa bağlantıyı verimli yönetir; ancak BEAM overhead’i nedeniyle latency PgBouncer’a göre yaklaşık 1-2 ms daha yüksektir.

AWS RDS Proxy: PostgreSQL ve Aurora PostgreSQL için yönetilen pooling. Lambda’lar için “in-place” çözüm; IAM authentication, secrets rotation, failover acceleration sağlar. Maliyet: vCPU başına saatlik yaklaşık 0.015 USD (yaklaşık değer, region’a göre değişir, resmi fiyatlandırma‘yı kontrol edin). Failover süresini ~60 saniyeden ~20 saniyenin altına indirebilir.

Google Cloud SQL Auth Proxy + PgBouncer: GCP Cloud SQL kendisi pooling sunmaz; resmi öneri ya Cloud SQL Auth Proxy’yi sidecar olarak çalıştırmak ya da GKE üstüne kendi PgBouncer’ınızı kurmak. AlloyDB ise dahili pooling sunar.

Çözüm	Tip	Maks. eşzamanlı	Min. latency	Aylık maliyet (yaklaşık)	Failover desteği
Self-host PgBouncer (t3.medium)	OSS	~10k	<1 ms	~30 USD (compute)	Manuel/HAProxy
Self-host PgCat (c6i.xlarge)	OSS	~25k	<1 ms	~120 USD	Built-in
AWS RDS Proxy	Managed	Instance’a bağlı	~3-5 ms	~250-500 USD	20 sn altı
Supabase Supavisor	Managed	1M+ (cluster)	~3-4 ms	Supabase planına dahil	Built-in
Cloud SQL + Proxy	Hybrid	Cloud SQL tier’a bağlı	~2-3 ms	~40 USD (proxy)	Cloud SQL HA üzerinden

Performance Benchmark: Gerçek Sayılar

Bir pooler’ın değerini ölçmenin tek doğru yolu kendi iş yükünüzle pgbench veya HammerDB çalıştırmaktır. Aşağıdaki tablo Brandur Leach’in “PgBouncer: How Far Can a Pool Take You” yazısı ve PgCat repo’sundaki benchmarks/ klasöründe yayımlanan ölçümlerin sentezidir; rakamlar yaklaşıktır ve donanım/iş yüküne göre büyük sapma gösterir.

Senaryo (pgbench -S, read-only, 16 vCPU client/server)	Doğrudan PG	PgBouncer (session)	PgBouncer (transaction)	PgCat
Bağlantı kurma süresi (yeni client)	~80-120 ms	~1-2 ms	~1-2 ms	~1-2 ms
100 client TPS	~95k	~92k	~92k	~95k
1000 client TPS (idle %80)	Crash/timeout	~75k	~110k	~190k
5000 client TPS (idle %95)	—	—	~115k	~280k
p99 latency (1000 client)	250+ ms	~12 ms	~8 ms	~6 ms
Pooler CPU kullanımı (1000 client)	—	~95% (tek core)	~95% (tek core)	~60% (tüm coreler)

Pratik çıkarımlar: (1) Bağlantı kurma maliyeti pooler ile ~50-100 kat düşer; serverless ortamlarda farkın anlamı budur. (2) PgBouncer transaction modu tek vCPU’da yaklaşık 100k TPS tavanına yakındır; bu sınıra ulaşıldığında ya birden fazla PgBouncer process’i (örn. so_reuseport + 4-8 process) ya da PgCat seçilmelidir. (3) PgCat’in multi-thread mimarisi 5k+ client senaryolarında PgBouncer’a göre 2-3 kat daha iyi ölçeklenir, fakat bu sayıların yakınına gelen ekiplerin oranı düşüktür.

Sık Yapılan Üç Ölümcül Hata

1. Transaction modunda named prepared statement kullanmak (PgBouncer 1.21 öncesi): Sürümünüzü kontrol edin. Eski PgBouncer’da Hibernate/SQLAlchemy gibi ORM’lerin otomatik prepared statement caching’i sessiz bozulmalara yol açar. Çözüm: 1.21+ kullanın ya da driver tarafında prepared statement cache’i kapatın (JDBC: prepareThreshold=0).
2. pool_size’ı çok yüksek tutmak: 500 client için pool_size=200 yapmak işe yaramaz, sadece PostgreSQL’i fork şişkinliğine boğar. Kural: Backend cap = (CPU × 2) + spindle; pooler oraya kadar çoklasın. Çözüm: pool_size = 25-50, max_client_conn = 5000.
3. PgBouncer’ı tek SPOF olarak konuşlandırmak: Pooler her zaman client ile DB arasındaki kritik yolda. Tek instance düşerse trafik durur. Çözüm: En az 2 PgBouncer (HAProxy/AWS NLB arkasında), keepalived veya Kubernetes Service ile.

Bu üç hatayı, müşteri sistemlerinde gerçek incident’lerde görmüş biri olarak söyleyebilirim: postmortem’lerin yarısı pool_mode/pool_size yanlışıdır. Ömer Önal olarak PostgreSQL altyapılarına dair danışmanlık verdiğim ekiplerde ilk denetlediğim parametre pool_mode, ikincisi server_lifetime oluyor.

Observability: PgBouncer’ı Üretimde İzlemek

Pooler kara kutu değil, telemetri ile beslenmesi gereken kritik bir bileşendir. Minimum izlenecek metrikler:

• cl_waiting (SHOW POOLS): Havuzdan bağlantı bekleyen client sayısı. 0’dan büyükse uygulama gecikme yaşıyor demektir. Alert eşiği: >5 sürekli.
• sv_active / sv_idle oranı: 0.8+ ise pool dolu, pool_size yetersiz olabilir.
• total_query_time / total_query_count: Ortalama sorgu süresi. Trend yukarı giderse DB sorununu pooler önceden hisseder.
• maxwait (saniye): En uzun bekleyen client’ın bekleme süresi. p99 alert: >1 sn.
• pg_stat_activity (DB tarafı): state='idle in transaction' sayısı; uygulama transaction’ı açık unutuyorsa burada birikir.

Açık kaynak pgbouncer_exporter Prometheus formatında bu metrikleri yayar. Grafana için hazır dashboard ID 9628 toplulukta yaygındır. PgCat ise Prometheus endpoint’ini (varsayılan port 9930) doğrudan açar; sharding-bazlı metrikleri de detaylı sunar.

Veri katmanı genelinde pooler metriklerini, sorgu performansı ve veri kalitesi metrikleriyle birlikte değerlendirmek gerekir; bu konuda PostgreSQL Performans yazısı sorgu seviyesi optimizasyona iner. Pooler’ın altındaki şema/index/vacuum kararları yanlışsa, dünyanın en iyi pooler’ı bile etkiyi sadece geciktirir. Daha geniş veri mimarisi için Data Lakehouse ve dbt Analytics Engineering yaklaşımları, OLTP/OLAP ayrımı içinde pooler kararını yerine oturtmaya yardımcı olur.

İleri Konular: Multi-Tenant, Sharding ve Read Replica Yönlendirme

Tek bir PostgreSQL primary’sini aşan ekipler için pooler katmanı, mimarinin asıl karar merkezine dönüşür. Üç senaryo özellikle yaygın:

Multi-tenant SaaS: Her tenant ayrı database (schema-per-tenant değil, db-per-tenant) ise PgBouncer’da [databases] bloğu binlerce satıra çıkar; auth_dbname ile dinamik tenant ekleme mümkündür. Alternatif: PgCat’in pool-by-pool config’i veya Supavisor’ın multi-tenant tasarımı. Stream processing ve event-driven veri akışı varsa Stream Processing tarafındaki Kafka consumer pool’u ile DB pool’u ayrı tutulmalı.

Yatay sharding: Citus eklentisi şard yönlendirmeyi DB içinde halleder; PgCat ise pooler katmanında. PgCat şard mantığını “müşteri_id’nin bigint hash’i mod N” ile çözer. Avantaj: Standart PostgreSQL kullanmaya devam edilir. Dezavantaj: Cross-shard JOIN uygulamada manuel. Veri mesh yaklaşımıyla domain bazlı pooler farklılaşması için Data Mesh Mimarisi okunabilir.

Read replica yönlendirme: En temiz çözüm uygulamanın iki ayrı connection string (writer/reader) bilmesidir; bu da iki ayrı PgBouncer pool’u demek. PgCat’in otomatik split’i çekici görünür ama SELECT … FOR UPDATE gibi durumları yanlış yönlendirebilir; üretimde query hint ile açık yönlendirme tercih edilir. Veri yönetişimi açısından replica’ya akan PII’nin de aynı KVKK/GDPR kapsamında olduğu unutulmamalı — bkz. Veri Yönetişimi.

Topoloji	Önerilen pooler	Avantaj	Dezavantaj
Tek primary + birkaç replica	2x PgBouncer (writer + reader)	Sade, kanıtlanmış	Manuel route gerekir
Multi-AZ HA (RDS/Aurora)	RDS Proxy	Failover hızlı, IAM	Vendor lock-in, ek maliyet
Sharded cluster (Citus yok)	PgCat	Native sharding	Olgunluk daha az
Multi-tenant SaaS (10k+ tenant)	Supavisor / PgCat	Dinamik tenant yönetimi	Setup karmaşık
Serverless / Lambda	RDS Proxy veya Supavisor	Bağlantı patlamasını absorbe eder	Cold start ek latency

Sıkça Sorulan Sorular

Sonuç

PostgreSQL’i pooler olmadan 2026’da üretime almak, otoyolu rampasız yapmaya benzer: trafik bir yere kadar akar, sonra durur. PgBouncer hâlâ %90 ekibin doğru cevabıdır — 17 yıl olgunluğa sahip, küçük binary, INI tabanlı şeffaf konfigürasyon, geniş topluluk. Transaction modu + 1.21+ sürümü + 25-50 arası pool_size, çoğu uygulama için altın oran. Yüksek throughput, sharding veya multi-thread ölçekleme istiyorsanız PgCat ciddi alternatif; managed çözüm arıyorsanız AWS ekosisteminde RDS Proxy, Supabase’de Supavisor, GCP’de AlloyDB tercihler arasında.

Karar çerçevesi netleşene kadar dikkat edilmesi gereken üç şey kalır: doğru pool_mode, doğru pool_size, ve HA için en az iki pooler instance’ı. Bunları yanlış kurmak, dünyanın en iyi PostgreSQL tuning’ini bile sonuçsuz bırakır. Pooler’ı doğru kurmak ise — çoğu zaman — bir DBA’ya günlerce sürecek olan “veritabanı yavaş” çağrılarını sessizce çözer.

Üretim PostgreSQL altyapınızda pooler topolojisini, connection metric’lerini ve failover senaryolarını birlikte gözden geçirmek için iletişim sayfası üzerinden ulaşabilirsiniz; mevcut konfigürasyon denetimi çoğu zaman birkaç saatte yapılır ve incident sayısını ölçülebilir biçimde düşürür.