Bağlantı Havuzlama (Connection Pooling)

Bağlantı havuzlama (connection pooling), her isteğin veritabanına yepyeni bir bağlantı açıp iş bittiğinde kapatması yerine, sabit sayıda önceden kurulmuş veritabanı bağlantısının açık tutulup gelen istekler arasında paylaşıldığı bir tekniktir. Bir veritabanı bağlantısı açmak, çalıştıracağı gerçek sorguya kıyasla pahalıdır - bir TCP el sıkışması, kimlik doğrulama ve (özellikle Postgres için) bağlantı başına özel bir backend süreç başlatmayı içerir - bu yüzden bunu her tek istekte yapmak, gecikme ve sunucu kaynakları üzerinde önemli, önlenebilir bir vergidir. AI/SaaS kurucuları için neden önemli: bu, özellikle şimdi yeni AI ürünlerinin büyük bir kısmı için varsayılan dağıtım modeli haline gelen sunucusuz (serverless) ve edge dağıtımlarında (Vercel, AWS Lambda, Cloudflare Workers) keskin, ürünü bozan bir soruna dönüşür. Sunucusuz fonksiyonlar sürekli başlatılıp durdurulur ve havuzlama olmadan, her çağırma kendi veritabanı bağlantısını açtığında, bu gerçek trafik altında saniyeler içinde Postgres'in oldukça düşük varsayılan bağlantı sınırını (genellikle 100) tüketebilir; bu da tüm uygulamayı çökerten "çok fazla bağlantı" hatalarına neden olur - bu, yerel geliştirmede ortaya çıkmayan ve yalnızca gerçek eşzamanlı kullanıcılar production'a çarptığında görünen bir başarısızlık modudur. Nasıl çalışır: bir bağlantı havuzlayıcı, uygulama ile veritabanı arasında durur, zaten açık bir bağlantı kümesini korur ve gerektiğinde isteklere dağıtır, bir istek bittiğinde onları kapatmak yerine havuza geri döndürür. Uygulama düzeyi havuzlar (çoğu veritabanı sürücüsüne ve ORM'ye yerleşik) tek, uzun süre çalışan bir sunucu süreci içinde çalışır; ama sunucusuz fonksiyonlar durumsuz ve kısa ömürlüdür, bu yüzden herhangi bir tek fonksiyon çağrısından bağımsız olarak kalıcı olan ve birçok sunucusuz bağlantıyı az sayıda gerçek veritabanı bağlantısına çoğullayan PgBouncer gibi harici bir havuzlayıcıya veya yönetilen bir eşdeğerine (Supabase'in yerleşik havuzlayıcısı, Neon'un bağlantı havuzlaması, PlanetScale'in proxy'si) ihtiyaç duyarlar. Somut örnek: Vercel sunucusuz fonksiyonlarında dağıtılmış bir AI SaaS, yük altında aralıklı 500 hataları görmeye başlar - Postgres logları `FATAL: too many connections` gösterir, çünkü yüzlerce eşzamanlı Lambda çağrısının her biri veritabanına kendi doğrudan bağlantısını açmıştır. Çözüm: uygulamanın veritabanı URL'sini işlem havuzlama (transaction-pooling) modunda PgBouncer üzerinden yönlendirmek; bu, o yüzlerce geçici sunucusuz bağlantıyı, sorgu kodunun tek bir satırını bile değiştirmeden, 20 gerçek backend bağlantısından oluşan istikrarlı bir havuza çoğullayarak bağlantı tükenmesi hatalarını ortadan kaldırır. Çözüm ayrıca ortalama sorgu gecikmesini de biraz azaltır, çünkü zaten açık olan havuzlanmış bir bağlantıyı yeniden kullanmak, önceden her tek çağırmada ödenen el sıkışma yükünden kaçınır - nadir görülen bir durumda, bir güvenilirlik hatasını düzeltmek ve performansı iyileştirmek tam olarak aynı değişiklikten gelir.