PostgreSQLPerformans ve kapasite 15 dk 15.06.2026

PostgreSQL ölçeklenebilirlik: connection pool, read replica, partitioning ve ne zaman yetmez?

PostgreSQL çoğu ürün için uzun süre çok iyi ölçeklenir; ama doğru sırayla. Önce sorgu ve bağlantı düzeni, sonra dikey kaynak, sonra read replica ve partitioning düşünülmelidir. Sharding en başta değil, gerçekten gerektiğinde konuşulmalıdır.

Bu yazı sana şu durumda yardımcı olur

PostgreSQL CPU sürekli yüksek
too many clients hatası sıklaşıyor
okuma sorguları yazma trafiğini yavaşlatıyor
büyük tabloda indeksler şişiyor
read replica ekleyelim mi yoksa sorgu mu düzeltelim kararsızlığı var

Yazıyı bitirince

PostgreSQL’i ne zaman pool ile, ne zaman kaynak büyüterek, ne zaman read replica veya partitioning ile ölçeklemeniz gerektiğini ayırabileceksiniz.

TürkDB açısından ürünleşme notu

Bu bölüm, TürkDB’nin ilgili problemi hangi ürün ilkeleri ve kontrol noktalarıyla ele alacağını anlatır. Kapsam, gerçek iş yükü ve ihtiyaçla birlikte netleşir.

TürkDB PostgreSQL tarafında bağlantı, yavaş sorgu, yedek/PITR, replica durumu ve kapasite sinyallerini aynı bağlamda göstermeyi hedefler. Bu sayede “makine büyütelim” kararından önce pool, sorgu, indeks ve okuma/yazma ayrımı daha net görülebilir.

İlk ölçek sorunu çoğu zaman bağlantıdır

PostgreSQL her bağlantı için kaynak tüketir. Uygulama pod sayısı arttığında, her pod kendi havuzunu açtığında ve arka plan workerları da aynı veritabanına bağlandığında bağlantı sayısı hızla büyür.

Bu durumda daha büyük makine almak kısa süre rahatlatabilir ama kök sorunu çözmez. PgBouncer veya doğru uygulama pool ayarı, PostgreSQL ölçeklenebilirliğinin ilk basamağıdır.

Bağlantı baskısını okuma

postgres-connection-pressure.sql

select state, count(*)
from pg_stat_activity
group by state
order by count(*) desc;

select datname, numbackends
from pg_stat_database
order by numbackends desc;

Read replica okuma yükü için iyidir, yazmayı büyütmez

Read replica, rapor, listeleme, dashboard veya read-only API trafiğini primary üzerinden almak için yararlıdır. Ama yazma yükünüz primary üzerinde kalır. Sipariş yazma, ödeme kaydı, stok güncelleme gibi işlemler replica ile büyümez.

Ayrıca replika gecikmesi ürün davranışını etkiler. Kullanıcı sipariş verdikten hemen sonra siparişini read replica üzerinden okumaya çalışıyorsa eski veri görebilir. Bu nedenle read-after-write beklentisi olan akışlar dikkatle ayrılmalıdır.

Raporlama ve ağır okuma replica için iyi adaydır.
Kritik son yazıyı hemen okuyan akışlar primaryden okumalıdır.
Replica lag metrikleri kullanıcı deneyimiyle birlikte izlenmelidir.
Replica, kötü sorguyu otomatik iyi sorguya dönüştürmez.

Partitioning büyüyen tabloyu yönetmek içindir

Partitioning çoğu zaman performans sihri gibi görülür. Asıl gücü, büyüyen tabloyu yönetilebilir fiziksel parçalara ayırmasıdır. Tarih aralığıyla sorgulanan event, ödeme hareketi veya log tablolarında işe yarayabilir.

Sorgular partition anahtarını kullanmıyorsa PostgreSQL yine çok fazla partition gezebilir. Bu yüzden partitioning, sorgu deseni ve veri yaşam döngüsüyle birlikte tasarlanmalıdır.

Kullanım örneği: SaaS ürününde büyüyen orders tablosu

SaaS ürününde orders tablosu her tenant için büyüyor olsun. İlk adım tenant_id ve created_at filtrelerini doğru indekslemektir. Listeleme sorguları hâlâ ağırsa pagination ve sorgu planı incelenir. Eski veri nadiren okunuyorsa tarih bazlı partitioning veya arşivleme gündeme gelir.

Ağır raporlar aynı primary üzerinde çalışıyorsa read replica veya ClickHouse’a event aktarımı daha sağlıklı olabilir. Böylece OLTP veritabanı sipariş yazmaya odaklanır.

Devam etmek istersen

Sorunu motor bazında derinleştirin

Benzer belirtiler farklı motorlarda farklı nedenlere dayanır; yayınlanan tüm rehberleri ana sayfadan takip edebilirsiniz.

Tüm makaleler