PostgreSQL Best Practices: Production (Üretim Ortamı) İçin 10 Temel Kural

PostgreSQL best practices, bir veritabanını production’da (üretim ortamında) güvenli, hızlı ve sürdürülebilir şekilde işletmek için uygulanan temel kurallardır. En kritik olanlar şunlardır: doğrulanmış yedekleme ve belirli bir ana geri dönüş (PITR), otomatik failover’lı yüksek erişilebilirlik, bağlantı havuzu, belleğe göre boyutlandırılmış ayarlar, en az yetki ilkesi ve şifreli bağlantılar, düzenli çalışan autovacuum, sürekli izleme ve desteklenen bir sürümde kalmak.

Bu rehber, PostgreSQL’i production’da işleten veya production’a almaya hazırlanan ekipler için hazırlandı. Önerileri on başlıkta topladık ve her birinde “neden” sorusunu yanıtladık. Bilgiler PostgreSQL 18 dokümantasyonuna dayanıyor; sorguları PostgreSQL 18 üzerinde kontrol ettik.

Kısaca: PostgreSQL İçin 10 Temel Kural

1. Desteklenen Bir Sürümde Kalın

PostgreSQL topluluğu her ana sürümü beş yıl destekler ve en az üç ayda bir ara sürüm yayımlar. Ara sürümler yalnızca hata ve güvenlik düzeltmesi içerir; dump veya pg_upgrade gerektirmez, genellikle paketlerin güncellenip servisin yeniden başlatılmasıyla uygulanır. Topluluk, her zaman güncel ara sürümün kullanılmasını önerir.

PostgreSQL 14’ten çıkış için hedef sürüm ve yöntem seçimini PostgreSQL 14 destek sonu rehberimizde ayrıntılı olarak anlattık.

2. Yedekleme: Geri Yüklenemeyen Yedek, Yedek Değildir

PostgreSQL üç yedekleme yaklaşımı sunar ve bunlar birbirinin alternatifi değil, tamamlayıcısıdır:

Production için önerimiz, pgBackRest gibi bir araçla fiziksel yedek ve sürekli WAL arşivlemesidir. Yedekler veritabanı sunucusunun dışında, tercihen farklı bir lokasyonda tutulmalı; fidye yazılımına karşı en az bir kopya değiştirilemez (immutable) depolamada olmalıdır.

3. Yüksek Erişilebilirlik: Failover’ı Otomatikleştirin

PostgreSQL, streaming replication ile bekleme (standby) sunucularını yerleşik olarak destekler. Ancak primary’nin arızalandığını tespit edip bir replikayı otomatik olarak primary yapan bir mekanizma içermez. Bu iş için yaygın çözüm Patroni ve onun karar vermek için kullandığı etcd gibi bir dağıtık yapılandırma deposudur.

• En az üç sunucu düşünün: bir primary, bir replika ve karar mekanizması (etcd) için tek sayıda üye. Üç etcd üyesi bir arızaya, beş üye iki arızaya dayanır.
• Veri kaybı toleransını belirleyin: asenkron replikasyonda failover anında son işlemler kaybolabilir. Kayıp kabul edilemiyorsa senkron replikasyon kullanın.
• Bağlantı adresini sabitleyin: uygulamalar sunucu adresine değil, sanal IP’ye, yük dengeleyiciye veya DNS adına bağlanmalıdır.
• Failover’ı test edin: canlıya almadan önce ve sonrasında düzenli aralıklarla.

Bu bileşenleri tutarlı biçimde kurmak için Autobase’i kullanıyoruz. Dikkat ettiğimiz noktaları Autobase ile yüksek erişilebilir PostgreSQL ortamı kurulumu yazımızda anlattık.

4. Bağlantı Havuzu Kullanın

PostgreSQL her bağlantı için işletim sisteminde ayrı bir süreç açar. Bağlantı sayısı arttıkça bellek kullanımı ve bağlam değiştirme maliyeti de artar. Yüzlerce veya binlerce eşzamanlı bağlantı açan uygulamalarda max_connections değerini yükseltmek çözüm değildir; çözüm, PgBouncer gibi bir bağlantı havuzudur.

Uygulamanın açıp kapatmadığı, boşta bekleyen bağlantılar da sık görülen bir sorundur. Özellikle bir işlem başlatıp tamamlamadan bekleyen oturumlar, VACUUM’un çalışmasını engeller. idle_in_transaction_session_timeout ile bu oturumları belirli bir süre sonra kapatın.

-- Sessions by state, and the oldest open transaction
SELECT state, count(*) AS sessions,
       max(now() - xact_start) AS oldest_transaction
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state
ORDER BY sessions DESC;

5. Bellek ve Checkpoint Ayarlarını Boyutlandırın

PostgreSQL’in varsayılan ayarları, küçük bir makinede çalışabilecek şekilde muhafazakâr seçilmiştir. Production sunucusunda ilk gözden geçirilmesi gereken ayarlar şunlardır:

work_mem en dikkatli ayarlanması gereken parametredir. Örneğin 64 MB’lık bir değer, karmaşık bir sorguda birden fazla kez kullanılabilir ve yüzlerce bağlantıyla çarpıldığında sunucunun belleğini aşabilir. Değeri genel olarak düşük tutup, yoğun raporlama sorgularında oturum veya rol düzeyinde yükseltmek daha güvenlidir.

6. İşletim Sistemini Veritabanına Göre Ayarlayın

7. Güvenlik: En Az Yetki, SCRAM ve TLS

• Uygulamaya süper kullanıcı vermeyin. Her uygulama kendi rolüyle bağlanmalı ve yalnızca kendi veritabanında gerekli yetkilere sahip olmalıdır. postgres rolü yalnızca yönetim için kullanılmalıdır.
• Parolaları SCRAM-SHA-256 ile saklayın. MD5 parola desteği PostgreSQL 18’de kaldırılma sürecine girdi; MD5 kullanan rolleri tespit edip parolalarını yenileyin.
• pg_hba.conf kurallarını dar tutun. Her kuralda belirli bir veritabanı, rol ve ağ belirtin; trust yöntemini ağ bağlantılarında asla kullanmayın.
• Bağlantıları şifreleyin. Uzak bağlantılarda hostssl kullanın; en düşük TLS sürümünü 1.2 olarak belirleyin.
• Veritabanını internete açmayın. 5432 portu yalnızca uygulama sunucularına açık olmalıdır.
• Yetkili işlemleri kayıt altına alın. Bağlantı, oturum kapanışı ve DDL işlemlerini loglayın; denetim gereksinimleri için pgAudit eklentisini değerlendirin.

-- Roles with superuser or other elevated attributes
SELECT rolname, rolsuper, rolcreaterole, rolcreatedb, rolreplication, rolbypassrls
FROM pg_roles
WHERE rolsuper OR rolcreaterole OR rolreplication OR rolbypassrls
ORDER BY rolname;
-- Roles still using MD5 password hashes
SELECT rolname FROM pg_authid WHERE rolpassword LIKE 'md5%';

8. Autovacuum’u Kapatmayın, Ayarlayın

PostgreSQL, güncellenen ve silinen satırların eski sürümlerini hemen silmez. Bu “ölü satırları” autovacuum temizler. Autovacuum aynı zamanda sorgu planlayıcısının istatistiklerini günceller ve işlem numarası taşmasını (transaction ID wraparound) önler. Autovacuum’u kapatmak, kısa vadede performans kazancı gibi görünse de orta vadede tabloların şişmesine ve en kötü durumda veritabanının yeni işlemleri kabul etmemesine yol açar.

Yoğun güncellenen büyük tablolarda varsayılan eşikler geç kalabilir. Bu tablolarda autovacuum’u tablo düzeyinde daha sık çalışacak şekilde ayarlayın ve aşağıdaki iki sorguyu düzenli olarak izleyin:

-- Tables with the most dead rows and their last autovacuum
SELECT relname, n_live_tup, n_dead_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 10;
-- Transaction ID age per database (autovacuum_freeze_max_age default: 200 million)
SELECT datname, age(datfrozenxid) AS xid_age
FROM pg_database
ORDER BY xid_age DESC;

9. Sürekli İzleme

İyi bir izleme düzeni, sorunları kullanıcılar fark etmeden önce gösterir. En az şu metrikler için alarm tanımlayın:

pg_stat_statements eklentisi, sorgu düzeyinde performans analizinin temelidir. shared_preload_libraries ayarına eklenip sunucu yeniden başlatıldıktan sonra kullanılabilir:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
-- Top 10 queries by total execution time
SELECT round(total_exec_time::numeric, 0) AS total_ms,
       calls,
       round(mean_exec_time::numeric, 1) AS mean_ms,
       left(query, 80) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Sunucu logunda da yavaş sorguları görmek için log_min_duration_statement ayarını (örneğin 1 saniye), kilit beklemeleri için log_lock_waits ve checkpoint davranışı için log_checkpoints ayarlarını açın.

10. Şemayı Baştan Doğru Tasarlayın

Hızlı Öz Değerlendirme

Aşağıdaki soruların her birine “evet” diyebiliyorsanız, PostgreSQL ortamınız sağlam temellere sahiptir:

1. Desteklenen bir ana sürüm ve en güncel ara sürüm mü çalışıyor?
2. Son üç ay içinde ayrı bir sunucuya geri yükleme testi yapıldı mı?
3. Primary sunucu kapandığında kimse müdahale etmeden bir replika devreye giriyor mu?
4. Uygulamalar bir bağlantı havuzu üzerinden mi bağlanıyor?
5. shared_buffers ve work_mem sunucunun belleğine göre mi ayarlandı?
6. Hiçbir uygulama süper kullanıcı yetkisiyle bağlanmıyor mu?
7. Uzak bağlantıların tamamı şifreli mi?
8. Autovacuum açık ve işlem numarası yaşı izleniyor mu?
9. Replikasyon gecikmesi, disk doluluğu ve yedekleme başarısı için alarm var mı?
10. Tüm tablolarda primary key var mı?

Aryasoft ile PostgreSQL

Aryasoft’un yalnızca kıdemli uzmanlardan oluşan ekibi, SQL Server için sunduğu hizmetleri PostgreSQL için de sunar: sağlık kontrolü, mimari ve kurulum, yüksek erişilebilirlik ve yedekleme tasarımı, performans iyileştirme, sürüm yükseltme ve SQL Server ya da Oracle’dan PostgreSQL’e geçiş. Bu rehberdeki kuralların ortamınızda ne ölçüde uygulandığını bir sağlık kontrolüyle ortaya koyar, bulguları öncelik sırasıyla raporlarız. Sürekli destek için uzaktan veritabanı yöneticisi (Remote DBA) hizmetini de içeren yönetilen veritabanı hizmetlerimizi inceleyebilirsiniz.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki bilgiler Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı.

1. PostgreSQL: Versioning Policy
2. PostgreSQL dokümantasyonu: Backup and Restore
3. PostgreSQL dokümantasyonu: Continuous Archiving and Point-in-Time Recovery
4. PostgreSQL dokümantasyonu: High Availability, Load Balancing, and Replication
5. PostgreSQL dokümantasyonu: Resource Consumption
6. PostgreSQL dokümantasyonu: Write Ahead Log
7. PostgreSQL dokümantasyonu: Query Planning (effective_cache_size)
8. PostgreSQL dokümantasyonu: Managing Kernel Resources (overcommit, huge pages)
9. PostgreSQL dokümantasyonu: Password Authentication
10. PostgreSQL dokümantasyonu: The pg_hba.conf File
11. PostgreSQL dokümantasyonu: Routine Vacuuming
12. PostgreSQL dokümantasyonu: The Cumulative Statistics System
13. PostgreSQL dokümantasyonu: pg_stat_statements
14. PostgreSQL dokümantasyonu: Client Connection Defaults (idle_in_transaction_session_timeout)
15. PostgreSQL dokümantasyonu: Identity Columns
16. PgBouncer: Features
17. Patroni dokümantasyonu