PostgreSQL Hosting Seçerken Nelere Bakılmalı?

SaaS ürünleri, ERP uygulamaları, e-ticaret sistemleri ve özel yazılım projeleri için veritabanı altyapısı çoğu zaman uygulamanın görünmeyen ama en kritik parçasıdır. Uygulama kodu iyi yazılmış olsa bile PostgreSQL tarafında kapasite, yedekleme, izleme ve bakım planı zayıfsa büyüme döneminde performans sorunları, kesintiler veya veri kaybı riski ortaya çıkabilir.

PostgreSQL güçlü, olgun ve esnek bir veritabanıdır. Ancak “PostgreSQL kurduk, çalışıyor” demek üretim ortamı için yeterli değildir. Doğru hosting veya cloud altyapısı; CPU, RAM, disk, I/O, yedekleme, güvenlik, izleme, bağlantı yönetimi ve büyüme planı birlikte düşünülerek seçilmelidir.

Bu yazıda PostgreSQL hosting seçerken dikkat edilmesi gereken başlıkları teknik ama anlaşılır bir kontrol listesiyle ele alıyoruz.

PostgreSQL hosting seçimi neden sıradan sunucu seçimi değildir?

Bir web uygulaması için klasik VDS seçerken genellikle CPU, RAM ve disk kapasitesine bakılır. Veritabanı tarafında ise bu üçlü tek başına yeterli değildir. PostgreSQL performansı çoğu zaman disk I/O, bellek ayarları, bağlantı sayısı, indeks yapısı, sorgu kalitesi ve yedekleme stratejisiyle doğrudan ilişkilidir.

Örneğin aynı CPU ve RAM’e sahip iki sunucudan biri NVMe disk ve doğru I/O limitiyle çok daha stabil çalışabilir. Ya da RAM yeterli gibi görünürken yanlış work_mem ve bağlantı ayarları yüzünden yoğun saatlerde beklenmeyen yavaşlamalar yaşanabilir.

Bu nedenle PostgreSQL hosting seçerken soru sadece “kaç GB RAM var?” olmamalıdır. Asıl soru şudur: Bu altyapı veritabanı iş yükünüzü güvenli, izlenebilir ve büyüyebilir şekilde taşıyabilir mi?

1. Kaynak planlaması: CPU, RAM ve disk I/O birlikte düşünülmeli

PostgreSQL iş yükleri uygulamaya göre ciddi farklılık gösterir. Bazı sistemler çoğunlukla okuma yapar; bazıları yoğun yazma, raporlama veya arka plan job’ları çalıştırır. Bu nedenle kaynak seçimi gerçek kullanım profiline göre yapılmalıdır.

• CPU: Karmaşık sorgular, raporlama ve eş zamanlı bağlantılar için önemlidir.
• RAM: Cache, bağlantılar ve sorgu çalışma alanı için kritik rol oynar.
• Disk: Özellikle yazma yoğun sistemlerde I/O performansı belirleyicidir.
• Ağ: Uygulama ve veritabanı farklı sunuculardaysa gecikme ve ağ stabilitesi önem kazanır.

Başlangıç aşamasındaki bir SaaS için küçük ama izlenebilir bir yapı yeterli olabilir. Ancak kullanıcı sayısı, veri hacmi ve raporlama ihtiyacı büyüdükçe dikey kaynak artırımı, ayrı veritabanı sunucusu veya yüksek erişilebilirlik senaryoları gündeme gelir.

2. Disk türü ve yedekleme stratejisi net olmalı

PostgreSQL’de disk performansı sadece hız meselesi değildir; veri güvenliğiyle de ilgilidir. NVMe diskler yüksek performans sağlayabilir; ancak yedekleme ve snapshot stratejisi olmadan hızlı disk tek başına güvenli bir çözüm değildir.

PostgreSQL için ideal yaklaşım şu bileşenleri birlikte içerir:

• Düzenli tam yedek
• WAL arşivleme veya en azından kısa aralıklı yedekleme planı
• Yedeklerin farklı lokasyonda saklanması
• Geri yükleme testlerinin periyodik yapılması
• Snapshot ile uygulama seviyesindeki dump yedeklerinin birbirini tamamlaması

Örnek basit dump komutu:

pg_dump -Fc -h 127.0.0.1 -U app_user app_db > app_db_$(date +%F).dump

Geri yükleme test edilmeden yedek “var” sayılmamalıdır. Asıl kritik metrik, yedeğin gerçekten çalışıp çalışmadığı ve ne kadar sürede geri dönebileceğinizdir.

3. İzleme olmadan performans yönetilemez

PostgreSQL tarafında sorunlar genellikle bir anda ortaya çıkmış gibi görünür; fakat çoğu zaman önceden sinyal verir. Disk kullanımı artar, bağlantı sayısı yükselir, yavaş sorgular çoğalır, autovacuum geride kalır veya replikasyon gecikmesi büyür.

Takip edilmesi gereken temel metrikler:

• CPU, RAM, disk kullanımı
• Disk I/O ve latency
• Aktif bağlantı sayısı
• Yavaş sorgular
• Database size ve tablo büyümesi
• Dead tuple / vacuum durumu
• Backup başarı/başarısızlık durumu

Basit kontrol komutları:

SELECT datname, numbackends FROM pg_stat_database;
SELECT relname, n_dead_tup FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 10;
SELECT pid, now() - query_start AS duration, query FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC;

Bu veriler düzenli takip edilmezse, performans problemi çoğu zaman kullanıcı şikâyeti geldikten sonra fark edilir.

4. Bağlantı limiti ve connection pooling planlanmalı

SaaS uygulamalarında yaygın sorunlardan biri, uygulama sunucularının PostgreSQL’e gereğinden fazla bağlantı açmasıdır. Trafik arttığında bağlantı sayısı hızla yükselir ve veritabanı kaynakları tüketilir.

Bu nedenle PostgreSQL hosting seçerken bağlantı yönetimi de düşünülmelidir. Özellikle Node.js, PHP-FPM, Python veya Java uygulamalarında connection pooling ayarları net olmalıdır. Daha yoğun sistemlerde PgBouncer gibi çözümler kullanılabilir.

# Örnek PgBouncer servis kontrolü
systemctl status pgbouncer
psql -p 6432 -h 127.0.0.1 -U app_user app_db

Bağlantı limiti sadece veritabanı ayarı değil; uygulama mimarisiyle birlikte ele alınması gereken bir kapasite konusudur.

5. Güvenlik: erişim, şifreleme ve yetki ayrımı

PostgreSQL sunucusunun güvenliği yalnızca güçlü parola kullanmakla sınırlı değildir. Üretim ortamında şu başlıklar mutlaka kontrol edilmelidir:

• Veritabanı portu internete açık mı?
• Uygulama sunucusu ile veritabanı arasında private network kullanılıyor mu?
• Her uygulama için ayrı kullanıcı ve minimum yetki var mı?
• Yedek dosyaları şifreli veya erişim kontrollü saklanıyor mu?
• Sunucu güncellemeleri düzenli yapılıyor mu?
• Loglarda başarısız login denemeleri izleniyor mu?

Çoğu senaryoda PostgreSQL’in internete doğrudan açık olması gerekmez. Uygulama ve veritabanı aynı private network içinde çalışmalı; dış erişim gerekiyorsa VPN, IP kısıtı veya güvenli tünel gibi yöntemler tercih edilmelidir.

6. Ölçekleme: Bugünün sunucusu yarının ihtiyacını karşılayacak mı?

Başlangıçta tek sunuculu PostgreSQL yeterli olabilir. Ancak zamanla veri büyür, raporlama ihtiyacı artar, müşteri sayısı yükselir ve uptime beklentisi sertleşir. Bu noktada ölçekleme planı devreye girer.

Değerlendirilebilecek senaryolar:

• Dikey ölçekleme: CPU/RAM/disk artırımı
• Okuma replikası: raporlama veya yoğun okuma trafiğini ayırma
• Ayrı veritabanı sunucusu: uygulama ve DB kaynaklarını ayırma
• Yüksek erişilebilirlik: failover ve replikasyon senaryoları
• Arşivleme: eski veriyi farklı depolama katmanına taşıma

Ölçekleme planı baştan düşünülürse, büyüme döneminde panik yerine kontrollü geçiş yapılabilir.

7. PostgreSQL hosting için kısa seçim checklist’i

[ ] CPU/RAM kapasitesi gerçek iş yüküne göre seçildi
[ ] Disk tipi ve I/O performansı değerlendirildi
[ ] Yedekleme sıklığı ve geri yükleme testi planlandı
[ ] İzleme metrikleri ve alarm eşikleri belirlendi
[ ] Connection pooling ihtiyacı kontrol edildi
[ ] Private network veya güvenli erişim yöntemi planlandı
[ ] Kullanıcı yetkileri minimum yetki prensibine göre ayrıldı
[ ] Ölçekleme ve büyüme senaryosu belirlendi
[ ] Teknik destek ve müdahale süresi netleştirildi

Narweb PostgreSQL Cluster Hosting ile daha dayanıklı veritabanı altyapısı

PostgreSQL altyapınız artık tek sunucunun kapasitesini zorluyorsa veya SaaS, ERP, e-ticaret gibi kritik sistemlerde daha kontrollü bir yapı istiyorsanız, Narweb PostgreSQL Cluster Hosting hizmetiyle veritabanı tarafını daha ölçeklenebilir ve izlenebilir şekilde planlayabilirsiniz.

Narweb PostgreSQL Cluster Hosting; yüksek erişilebilirlik, replikasyon, yedekleme, izleme ve büyüme senaryolarını birlikte ele alarak PostgreSQL iş yükünüz için daha güvenli bir operasyon modeli kurmanıza yardımcı olur. Böylece sadece “PostgreSQL çalışan bir sunucu” değil; performans, yedekleme ve süreklilik tarafı düşünülmüş bir veritabanı altyapısı elde edersiniz.

Mevcut PostgreSQL kurulumunuzun kapasitesinden, yedekleme planından veya ölçekleme ihtiyacından emin değilseniz Narweb teknik ekibiyle görüşebilir; iş yükünüze uygun VDS, Cloud Dedicated Server veya PostgreSQL Cluster Hosting mimarisini birlikte değerlendirebilirsiniz.

PostgreSQL Cluster Hosting hizmetimizi inceleyin veya WhatsApp üzerinden bize ulaşarak altyapınızı birlikte değerlendirelim.