PostgreSQL Sunucularda Performans Optimizasyonu ve Güvenli Erişim Rehberi

Son Güncelleme: Eylül 2026

PostgreSQL performans optimizasyonu, veritabanı odaklı web uygulamalarında hız, kararlılık ve ölçeklenebilirlik için kritik öneme sahiptir. Doğru yapılandırılmış bir PostgreSQL sunucusu, hem sorgu sürelerini azaltır hem de yüksek trafik altında veri bütünlüğünü korur. Bu rehberde bellek ayarlarından bağlantı güvenliğine, yedekleme stratejisinden izleme metriklerine kadar pratik bir yol haritası bulacaksınız.

İçindekiler

• PostgreSQL Nedir ve Sunucularda Neden Tercih Edilir?
• Mimari ve Kaynak Planlaması
• Kurulum Sonrası İlk Kontroller
• Bellek, Sorgu ve İndeks Optimizasyonu
• Güvenli Erişim ve Bağlantı Yönetimi
• Yedekleme, Bakım ve Veri Sağlığı
• İzleme ve Sorun Giderme
• Pratik Kullanım Senaryoları
• Sıkça Sorulan Sorular
• Sonuç

PostgreSQL Nedir ve Sunucularda Neden Tercih Edilir?

PostgreSQL, açık kaynaklı, ilişkisel ve nesne ilişkisel özellikler sunan gelişmiş bir veritabanı yönetim sistemidir. Web uygulamaları, kurumsal yazılımlar, e-ticaret platformları, raporlama sistemleri ve coğrafi veri işleme projelerinde yaygın şekilde kullanılır. Güçlü işlem yönetimi, veri bütünlüğü, gelişmiş indeksleme seçenekleri ve geniş eklenti desteği sayesinde küçük projelerden büyük ölçekli sistemlere kadar esnek bir yapı sunar.

PostgreSQL’in en önemli avantajlarından biri, ACID uyumluluğudur. ACID; atomiklik, tutarlılık, izolasyon ve kalıcılık ilkelerini ifade eder. Bu ilkeler, özellikle ödeme sistemleri, sipariş yönetimi, kullanıcı hesapları ve kritik iş verileri için güvenilir kayıt işlemleri sağlar. Yanlış yapılandırılmış bir veritabanı ise güçlü donanıma rağmen yavaş çalışabilir, bağlantı limitlerine takılabilir veya disk giriş çıkış yükü nedeniyle beklenmedik kesintiler yaşayabilir.

Bu nedenle PostgreSQL’i yalnızca kurmak yeterli değildir. Sunucunun işlemci, bellek, disk, ağ ve güvenlik yapısına göre optimize edilmesi gerekir. Corelux üzerinde Sanal Sunucu, Türkiye VDS Sunucu veya yüksek kaynak gerektiren projeler için Kiralık Sunucu kullanırken PostgreSQL ayarlarını doğru planlamak, uygulama performansını doğrudan etkiler.

Mimari ve Kaynak Planlaması

Başarılı bir PostgreSQL mimarisi, veritabanının hangi iş yükünü taşıyacağını anlamakla başlar. Okuma ağırlıklı bir blog, yazma yoğun bir stok sistemi, karmaşık raporlar üreten bir analiz paneli veya sürekli işlem yapan bir finans uygulaması aynı ayarlarla verimli çalışmaz. Bu nedenle kaynak planlaması yapılırken eş zamanlı bağlantı sayısı, tablo büyüklüğü, sorgu karmaşıklığı, beklenen trafik, veri büyüme hızı ve yedekleme politikası birlikte değerlendirilmelidir.

İş Yükünü Sınıflandırma

• Okuma ağırlıklı sistemler: Haber siteleri, kataloglar ve raporlama panellerinde önbellek, indeks ve replikasyon daha belirleyicidir.
• Yazma ağırlıklı sistemler: Sipariş, log, kuyruk ve işlem kayıtlarında disk performansı, WAL ayarları ve transaction yönetimi öne çıkar.
• Karma iş yükleri: E-ticaret, CRM ve SaaS uygulamalarında bağlantı havuzu, indeks stratejisi ve sorgu planı düzenli izlenmelidir.
• Analitik sistemler: Büyük veri kümelerinde bölümleme, materialized view ve doğru çalışma belleği kullanımı önem kazanır.

Sunucu Kaynaklarının Rolü

PostgreSQL bellekten yoğun şekilde faydalanır; ancak tüm performans belleğe bağlı değildir. Hızlı NVMe diskler, düşük gecikmeli ağ, yeterli işlemci çekirdeği ve dengeli dosya sistemi ayarları da toplam performansa katkı sağlar. Veritabanı sunucusu aynı makinede web sunucusu, Redis, kuyruk işleyici ve yedekleme servisiyle birlikte çalışıyorsa kaynak yarışması oluşabilir. Bu durumda veritabanı için ayrılmış kaynaklara sahip bir Türkiye VDS Sunucu ya da daha yüksek giriş çıkış performansı gerektiren projelerde Türkiye Kiralık Sunucu daha doğru bir tercih olabilir.

Kurulum Sonrası İlk Kontroller

PostgreSQL kurulduktan sonra üretim ortamına geçmeden önce temel servis, sürüm, port, veri dizini ve kullanıcı kontrolleri yapılmalıdır. Bu aşama, ileride yaşanabilecek bağlantı hatalarının ve güvenlik açıklarının önüne geçer. Linux sunucularda genellikle servis adı postgresql olarak yönetilir; dağıtıma göre paket sürümü ve dizin yolu farklılık gösterebilir.

Servis Durumunu Kontrol Etme

systemctl status postgresql

Servis aktif değilse başlatılabilir ve açılışta otomatik çalışması sağlanabilir:

systemctl enable --now postgresql

Sürüm ve Bağlantı Testi

sudo -u postgres psql -c "SELECT version();"

Bu komut, PostgreSQL servisinin yanıt verdiğini ve temel istemci bağlantısının çalıştığını gösterir. Üretim ortamında varsayılan postgres kullanıcısıyla uygulama bağlantısı yapılmamalı, her uygulama için ayrı rol ve ayrı veritabanı oluşturulmalıdır.

Uygulama Kullanıcısı Oluşturma

sudo -u postgres psql
CREATE DATABASE appdb;
CREATE USER appuser WITH ENCRYPTED PASSWORD 'GucluParolaDegistir';
GRANT ALL PRIVILEGES ON DATABASE appdb TO appuser;
\q

Parola örnek olarak verilmiştir; gerçek ortamda uzun, rastgele ve parola kasasında saklanan değerler kullanılmalıdır. Ayrıca uygulama kullanıcısına yalnızca ihtiyacı olan yetkiler tanımlanmalıdır. Gereksiz SUPERUSER, CREATEDB veya CREATEROLE izinleri verilmemelidir.

Bellek, Sorgu ve İndeks Optimizasyonu

PostgreSQL performansında en sık yapılan hata, ayarları donanım özelliklerine göre düzenlememektir. Varsayılan değerler çoğu dağıtımda güvenli ve genel amaçlıdır; ancak yüksek trafik alan web uygulamaları için genellikle yetersiz kalır. Temel yapılandırma dosyası çoğunlukla postgresql.conf dosyasıdır. Değişikliklerden sonra servis yeniden yüklenmeli veya yeniden başlatılmalıdır.

Önemli Bellek Parametreleri

• shared_buffers: PostgreSQL’in kendi bellek önbelleği için ayırdığı alandır. Genellikle toplam belleğin belirli bir bölümüyle başlanır ve izleme sonuçlarına göre ayarlanır.
• effective_cache_size: PostgreSQL sorgu planlayıcısına işletim sistemi önbelleği dahil ne kadar veri önbelleği beklenebileceğini bildirir. Bu bir bellek ayırma değeri değil, tahmin değeridir.
• work_mem: Sıralama, hash join ve aggregate işlemlerinde bağlantı başına kullanılabilecek belleği belirler. Çok yüksek ayarlanırsa çok sayıda eş zamanlı sorguda bellek baskısı oluşur.
• maintenance_work_mem: VACUUM, CREATE INDEX ve bakım işlemlerinde kullanılan belleği etkiler.

Örnek bir başlangıç yapılandırması aşağıdaki gibi olabilir. Bu değerler her sunucu için doğrudan kopyalanmamalı, mevcut RAM, bağlantı sayısı ve iş yüküne göre uyarlanmalıdır:

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
max_connections = 100

Bağlantı Sayısı ve Connection Pooling

PostgreSQL’de her bağlantı belirli miktarda kaynak tüketir. Uygulama tarafında sınırsız bağlantı açmak, güçlü bir sunucuda bile performans sorunlarına neden olabilir. Özellikle PHP, Laravel, Node.js, Python veya Java tabanlı uygulamalarda connection pooling yani bağlantı havuzlama yaklaşımı kullanılmalıdır. Bağlantı havuzu, her istek için yeni bağlantı oluşturmak yerine mevcut bağlantıları yeniden kullanır.

Yüksek trafikli sistemlerde PgBouncer gibi hafif bağlantı havuzlayıcılar tercih edilebilir. Bu yaklaşım, veritabanı üzerindeki bağlantı yükünü azaltır ve uygulamanın daha dengeli çalışmasını sağlar. Ancak transaction yapısı, prepared statement kullanımı ve uygulama davranışı test edilmeden canlı ortama alınmamalıdır.

EXPLAIN ile Sorgu Planı İnceleme

Yavaş sorguları optimize etmenin en doğru yolu tahmin yürütmek değil, sorgu planını incelemektir. PostgreSQL’de EXPLAIN ve EXPLAIN ANALYZE komutları, sorgunun tabloyu nasıl taradığını, hangi indeksi kullandığını ve hangi adımda zaman harcadığını gösterir.

EXPLAIN ANALYZE
SELECT * FROM orders
WHERE customer_id = 42
ORDER BY created_at DESC
LIMIT 20;

Bu sorguda customer_id ve created_at alanları sık birlikte kullanılıyorsa birleşik indeks faydalı olabilir:

CREATE INDEX idx_orders_customer_created
ON orders (customer_id, created_at DESC);

Her sütuna indeks eklemek doğru değildir. İndeksler okuma performansını artırabilir; fakat yazma işlemlerinde ek maliyet oluşturur ve disk alanı tüketir. Bu nedenle indeks stratejisi gerçek sorgu örüntülerine göre belirlenmelidir.

Güvenli Erişim ve Bağlantı Yönetimi

Veritabanı güvenliği, yalnızca güçlü parola kullanmaktan ibaret değildir. PostgreSQL sunucusunda ağ erişimi, kimlik doğrulama yöntemi, kullanıcı yetkileri, SSL şifreleme, firewall kuralları ve log kayıtları birlikte ele alınmalıdır. Özellikle veritabanı internete açık olacaksa riskler dikkatle değerlendirilmelidir. Mümkün olduğunda veritabanı yalnızca uygulama sunucusunun özel IP adresinden erişilebilir olmalıdır.

listen_addresses Ayarı

postgresql.conf içindeki listen_addresses parametresi, PostgreSQL’in hangi IP adreslerinde dinleme yapacağını belirler. Yerel kullanım için localhost yeterlidir. Uzak uygulama sunucularının bağlanması gerekiyorsa yalnızca gerekli özel IP adresleri tercih edilmelidir.

listen_addresses = '127.0.0.1,10.10.10.5'

pg_hba.conf ile Erişim Kuralı

pg_hba.conf dosyası, hangi kullanıcıların hangi veritabanına hangi ağdan ve hangi kimlik doğrulama yöntemiyle bağlanabileceğini tanımlar. Geniş ağ aralıkları yerine mümkün olduğunca dar IP tanımları kullanılmalıdır.

host    appdb    appuser    10.10.10.20/32    scram-sha-256

Bu örnekte yalnızca 10.10.10.20 IP adresindeki uygulama sunucusu, appuser kullanıcısıyla appdb veritabanına bağlanabilir. Daha güvenli parola saklama ve kimlik doğrulama için modern sistemlerde scram-sha-256 yöntemi tercih edilmelidir.

Firewall ve Port Yönetimi

PostgreSQL varsayılan olarak 5432 portunu kullanır. Bu portun herkese açık olması önerilmez. Linux sunucularda firewall ile yalnızca uygulama sunucusunun IP adresine izin verilebilir:

ufw allow from 10.10.10.20 to any port 5432 proto tcp
ufw deny 5432/tcp

Kurallar uygulanmadan önce SSH erişiminin kesilmemesi için mevcut yönetim portlarının izinli olduğundan emin olunmalıdır. Ayrıca kritik veritabanları için VPN, özel ağ veya güvenli tünel mimarisi değerlendirilebilir.

SSL ile Şifreli Bağlantı

Uygulama ile veritabanı farklı sunucularda bulunuyorsa ağ trafiğinin şifrelenmesi önemlidir. PostgreSQL SSL desteğiyle istemci ve sunucu arasındaki veri akışı şifrelenebilir. Web siteleri için kullanılan sertifika yaklaşımına benzer şekilde, veritabanı tarafında da güvenilir sertifika yönetimi yapılmalıdır. Sertifika ihtiyaçlarında Corelux SSL Sertifikası hizmetinden yararlanarak güvenli iletişim mimarisinin bir parçası oluşturulabilir.

Yedekleme, Bakım ve Veri Sağlığı

Performans kadar önemli bir diğer konu da veri sürekliliğidir. Veritabanı yedeği olmayan bir sistem, en iyi optimizasyon ayarlarına sahip olsa bile ciddi operasyonel risk taşır. PostgreSQL’de mantıksal yedekleme, fiziksel yedekleme, sürekli arşivleme ve replikasyon gibi farklı seçenekler bulunur. Hangi yöntemin seçileceği veri büyüklüğü, geri dönüş süresi hedefi ve kabul edilebilir veri kaybı süresine göre belirlenmelidir.

pg_dump ile Mantıksal Yedek

Küçük ve orta ölçekli veritabanlarında pg_dump pratik bir yöntemdir. Tek veritabanını taşımak, test ortamı oluşturmak veya sürüm geçişinde veri aktarmak için kullanılabilir.

pg_dump -U appuser -h localhost -F c -f appdb_backup.dump appdb

Geri yükleme için pg_restore komutu kullanılabilir:

pg_restore -U appuser -h localhost -d appdb appdb_backup.dump

VACUUM ve ANALYZE

PostgreSQL, güncellenen veya silinen satırları hemen fiziksel olarak kaldırmaz. Bu nedenle VACUUM işlemi, tablo şişmesini azaltmak ve kullanılmayan alanı yönetmek için önemlidir. ANALYZE ise sorgu planlayıcısının doğru istatistiklerle çalışmasını sağlar. Otomatik vacuum genellikle aktiftir; ancak yoğun yazma yapılan tablolarda ayarlar izlenmeli ve gerekirse tablo bazlı düzenlenmelidir.

VACUUM ANALYZE orders;

Yedekleri Test Etme

Bir yedeğin var olması yeterli değildir; geri yüklenebilir olması gerekir. Belirli aralıklarla test sunucusunda geri dönüş denemesi yapılmalı, işlem süresi ölçülmeli ve belgelenmelidir. Yedek dosyaları ayrı bir depolama alanında saklanmalı, erişim yetkileri sınırlandırılmalı ve mümkünse şifrelenmelidir. Kurumsal projeler için Corelux Yedekleme Hizmeti, veritabanı sürekliliği planının tamamlayıcı bir parçası olarak değerlendirilebilir.

İzleme ve Sorun Giderme

PostgreSQL optimizasyonu tek seferlik bir işlem değildir. Trafik arttıkça, veri büyüdükçe, yeni özellikler eklendikçe ve sorgu yapısı değiştikçe performans profili de değişir. Bu nedenle düzenli izleme, yavaş sorgu tespiti ve kaynak kullanım analizi gerekir. İzleme yapılmayan sistemlerde sorunlar genellikle kullanıcı şikayetiyle fark edilir; bu da müdahale süresini uzatır.

Temel İzleme Metrikleri

• Aktif bağlantılar: max_connections limitine yaklaşılması uygulama tarafında havuzlama sorunu olduğunu gösterebilir.
• Yavaş sorgular: Belirli eşiğin üzerindeki sorgular loglanmalı ve düzenli analiz edilmelidir.
• Disk kullanımı: Veri dizini, WAL dosyaları ve yedekler ayrı ayrı izlenmelidir.
• Cache hit ratio: Verilerin ne kadarının disk yerine bellekten karşılandığını anlamaya yardımcı olur.
• Lock beklemeleri: Uzun transaction veya hatalı sorgular tablo kilitlenmelerine yol açabilir.

Yavaş Sorgu Loglarını Açma

Belirli süreden uzun süren sorguları loglamak, performans problemlerini yakalamanın etkili bir yoludur. Örneğin 1 saniyeden uzun sorgular için aşağıdaki ayar kullanılabilir:

log_min_duration_statement = 1000
log_line_prefix = '%m [%p] %u@%d '
logging_collector = on

Bu loglar incelenirken tek bir yavaş sorguya odaklanmak yerine tekrar sıklığı, toplam süre, çağrı kaynağı ve indeks kullanımı birlikte değerlendirilmelidir. Nadiren çalışan ağır bir rapor sorgusu ile saniyede yüzlerce kez çalışan orta yavaşlıkta bir sorgunun etkisi aynı değildir.

Canlı Bağlantıları Görüntüleme

SELECT pid, usename, datname, state, query_start, query
FROM pg_stat_activity
ORDER BY query_start ASC;

Bu çıktı, aktif sorguları ve bekleyen bağlantıları görmeyi sağlar. Uzun süredir açık kalan transaction kayıtları tablo şişmesine ve vacuum işlemlerinin etkisiz kalmasına neden olabilir. Gerektiğinde uygulama kodu incelenmeli, açık transaction bırakılmadığından emin olunmalıdır.

Pratik Kullanım Senaryoları

PostgreSQL yapılandırmasını daha anlaşılır hale getirmek için farklı kullanım senaryolarını ele almak faydalıdır. Her senaryoda kaynak, güvenlik ve bakım öncelikleri değişebilir. Aşağıdaki örnekler doğrudan kopyalanacak kesin şablonlar değil, planlama için başlangıç noktalarıdır.

E-Ticaret Sitesi

E-ticaret sistemlerinde ürün listeleme, stok kontrolü, sepet işlemleri, sipariş kayıtları ve ödeme akışı aynı anda çalışır. Bu tür sistemlerde veri tutarlılığı ve hızlı okuma performansı birlikte önemlidir. Ürün arama için uygun indeksler, sipariş tabloları için doğru transaction yönetimi, ödeme kayıtları için güvenli bağlantı ve düzenli yedekleme zorunludur. Kampanya dönemlerinde bağlantı havuzu limitleri önceden test edilmelidir.

SaaS Uygulaması

SaaS projelerinde çoklu müşteri yapısı nedeniyle tablo tasarımı kritik hale gelir. Her müşteriye ayrı veritabanı, ayrı şema veya ortak tabloda tenant kimliği kullanımı gibi farklı yaklaşımlar vardır. Ortak tablo yaklaşımında her sorguda tenant filtresinin doğru kullanılması ve bu alan üzerinde uygun indekslerin oluşturulması gerekir. Ayrıca müşteri bazlı raporlama sorguları yoğun kaynak tüketebileceğinden arka plan işleriyle ayrıştırılmalıdır.

Yoğun Log Toplama Sistemi

Log sistemlerinde yazma hacmi yüksektir ve eski verilerin düzenli temizlenmesi gerekir. Bu senaryoda tablo bölümleme yani partitioning yaklaşımı faydalı olabilir. Günlük veya aylık bölümler sayesinde eski veriler hızlı şekilde arşivlenebilir ya da kaldırılabilir. Ancak bölümleme yanlış tasarlanırsa sorgu karmaşıklığı artabilir. Bu nedenle sorguların tarih filtresiyle uyumlu çalışması sağlanmalıdır.

Ayrı Veritabanı Sunucusu Kullanımı

Uygulama ve veritabanını aynı makinede çalıştırmak küçük projeler için yeterli olabilir; ancak trafik arttıkça ayrıştırma gerekebilir. Ayrı veritabanı sunucusu, kaynak izolasyonu ve daha net güvenlik sınırları sağlar. Corelux üzerinde Bulut Sunucu veya Almanya VDS Sunucu seçenekleriyle uygulama mimarisine göre farklı lokasyon ve kaynak planları oluşturulabilir. Kullanıcı kitlesi Türkiye’deyse düşük gecikme için Türkiye lokasyonlu çözümler çoğu zaman daha avantajlıdır.

Sıkça Sorulan Sorular

Sonuç

PostgreSQL sunucu optimizasyonu, donanım seçimi, bellek ayarları, sorgu analizi, güvenli erişim, düzenli bakım ve yedekleme stratejisinin birlikte ele alınmasıyla başarılı olur. Varsayılan kurulumla çalışan bir PostgreSQL sistemi başlangıç için yeterli görünse de trafik ve veri hacmi arttıkça darboğazlar ortaya çıkabilir. Bu nedenle canlı ortama geçmeden önce bağlantı limitleri, indeksler, firewall kuralları, yedekleme planı ve izleme metrikleri netleştirilmelidir.

Corelux altyapısında projenizin ölçeğine göre Linux Hosting, Sanal Sunucu, Kiralık Sunucu veya veritabanı odaklı daha güçlü kaynaklara sahip çözümler tercih edebilirsiniz. Doğru sunucu planı, düzenli yedekleme ve güvenli bağlantı mimarisiyle PostgreSQL tabanlı uygulamalarınızı daha hızlı, daha güvenli ve daha sürdürülebilir şekilde yayınlayabilirsiniz.