PostgreSQL Tuning: shared_buffers, WAL ve Üretim Konfigürasyonu 2026

Postgres tuning 2026 itibarıyla artık “shared_buffers’ı RAM’in %25’i yap” gibi kabaca kurallarla bitirilebilecek bir iş değil. Stack Overflow 2024 Developer Survey’inde PostgreSQL %49 ile en çok kullanılan ve en sevilen ilişkisel veritabanı çıktı; bu da üretimde çok farklı iş yüklerinin (OLTP, raporlama, jsonb-ağırlıklı, vektör arama) aynı motorun üzerine yığıldığı anlamına geliyor. Doğru cevap workload profiline ve donanıma göre değişiyor: 64 GB RAM’li bir e-ticaret OLTP node’unda shared_buffers=16GB, effective_cache_size=48GB, wal_compression=zstd, checkpoint_timeout=15min ve max_wal_size=16GB kombinasyonu hem latency hem throughput tarafında ölçülebilir kazanım üretir. Bu yazı; shared_buffers, WAL, checkpoint, autovacuum, planner ve connection katmanlarını gerçek rakamlarla, üretim referansıyla baştan sona ele alıyor.

Hedef şu: parametre listesi vermek değil, her parametrenin nereden ne kadar performans çıkardığını ve hangi anti-pattern’in production’da gece 03:00’te uyandırdığını göstermek. Aşağıda PostgreSQL 16 ve 17 referans alındı; sürüm farkları gerektiğinde belirtildi.

1. shared_buffers ve OS Page Cache İlişkisi

PostgreSQL, kendi buffer pool’unu (shared_buffers) işletim sisteminin page cache’i ile çift katmanlı kullanır. Sayfa önce shared_buffers’a okunur; oradan eviction olduğunda OS cache’de kalmaya devam eder. Bu yüzden klasik “RAM’in %25’i” tavsiyesi 2026’da hâlâ iyi bir başlangıç, ama mutlak değil. Yüksek write-heavy workload’larda %15-20 daha verimli olabiliyor; çünkü dirty buffer baskısı checkpoint maliyetini artırıyor.

EnterpriseDB ve AWS RDS PostgreSQL benchmark notlarına göre 64 GB RAM’li bir t-shirt-size makinede shared_buffers’ı 8 GB’tan 16 GB’a çıkarmak pgbench TPC-B benzeri yükte yaklaşık %12-18 throughput kazandırıyor; 32 GB’a çıkarmak çoğu OLTP profilinde ek %3-5 katkı verirken checkpoint sürelerini %40’a kadar uzatıyor. Yani lineer değil, marjinal getiri hızla düşüyor.

Pratikte üç boyut takip edilir: pg_buffercache ile cache hit ratio (hedef >%99), pg_stat_database.blks_hit / (blks_hit+blks_read) oranı ve OS tarafında vmstat‘tan major fault sayısı. Aşağıdaki tablo donanım büyüklüğüne göre üretimde doğrulanmış başlangıç değerlerini özetliyor.

RAM	shared_buffers	effective_cache_size	work_mem	maintenance_work_mem	Tipik Profil
8 GB	2 GB	6 GB	16 MB	512 MB	Küçük SaaS / dev
16 GB	4 GB	12 GB	32 MB	1 GB	OLTP başlangıç
32 GB	8 GB	24 GB	64 MB	2 GB	Orta OLTP + raporlama
64 GB	16 GB	48 GB	128 MB	4 GB	Yoğun OLTP, jsonb
128 GB	24-32 GB	96 GB	256 MB	8 GB	Karma OLTP + DW
256 GB+	32-48 GB	192 GB+	512 MB	16 GB	Büyük single-node

Burada dikkat: shared_buffers‘ı 40 GB’ın üzerine çıkarmak çoğu workload’da kayıp getirir. Çünkü buffer hash table büyür, dirty buffer scan maliyeti artar ve checkpoint sırasında double-write benzeri side-effect’ler oluşur. Tek seferde değiştirmek yerine kademeli artırıp pg_stat_bgwriter‘daki buffers_checkpoint ve buffers_clean sayaçlarını izlemek gerekir.

2. WAL Mimarisi: write-ahead log, full_page_writes ve sıkıştırma

WAL (Write-Ahead Log) Postgres’in dayanıklılık (durability) ve replikasyon temelidir. Her commit’te WAL fsync edilir; bu yüzden WAL’in bulunduğu disk Postgres’in en kritik I/O hattıdır. NVMe SSD üzerinde tipik fsync latency 80-200 µs aralığında; SATA SSD’de 400-800 µs; HDD’de ise 5-15 ms. Bu fark direkt commit-per-second tavanını belirler.

PostgreSQL 16 ile gelen wal_compression=zstd (önceki sürümlerde pglz veya lz4) full_page_image yazımlarını %50-65 küçültür ve WAL hacmini ölçülebilir biçimde düşürür. WAL hacmi düştüğünde hem disk doluluk hızı azalır hem replikasyon throughput’u artar hem de PITR backup boyutu küçülür. Daha derin replikasyon konusu için PostgreSQL performans optimizasyonu yazısındaki replication slot bölümüne bakılabilir.

WAL ile ilgili production’da kritik 6 parametre:

• wal_level = replica (logical replication varsa logical). Ne zaman seç: logical sadece CDC veya tablo bazlı replikasyon gerekirse.
• max_wal_size = 8-32 GB (yüksek throughput’ta 64 GB’a kadar). Avantaj: checkpoint sıklığını azaltır. Dezavantaj: crash recovery süresini uzatır.
• min_wal_size = 2-4 GB. WAL segment dosyalarının recycle’a girmeden tutulmasını sağlar.
• wal_compression = zstd (PG 16+). %50-65 WAL küçülmesi.
• wal_buffers = -1 (otomatik, shared_buffers/32). Manuel 16-64 MB iyi tavandır.
• synchronous_commit = on (default) veya remote_apply (HA cluster). Ne zaman seç: data-loss tolere edilen analytics ingest için off %30-50 throughput verir ama crash’te son işlemler kaybolur.

3. Checkpoint Davranışı ve I/O Spike Yönetimi

Checkpoint, dirty buffer’ların diske flush edildiği noktadır. Çok sık olursa I/O sürekli yüksek; çok seyrek olursa crash recovery uzar ve aradaki dönemde WAL şişer. checkpoint_timeout ve max_wal_size birlikte çalışır: hangisi önce dolarsa checkpoint o tetiklenir.

Üretimde “timed checkpoint” (zamana bağlı) tercih edilir; “requested checkpoint” (max_wal_size’ı patlatma) sinyaldir, ayar hatasıdır. pg_stat_bgwriter‘da checkpoints_req / (checkpoints_req + checkpoints_timed) oranı <%5 olmalı.

Workload	checkpoint_timeout	max_wal_size	checkpoint_completion_target	Beklenen I/O Profili
Düşük yazma OLTP	5 min	4 GB	0.9	Düşük, düzenli
Orta OLTP	10 min	8 GB	0.9	Orta, smoothed
Yoğun OLTP	15 min	16 GB	0.9	Yüksek ama uzun yayılı
Bulk ingest	30 min	32-64 GB	0.85	Büyük spike, uzun arayla
DW / ETL	30 min	32 GB	0.85	Toplu yazma penceresi

checkpoint_completion_target=0.9, fsync’lerin checkpoint penceresinin %90’ına yayılması demektir. Bu yayılma OS dirty page baskısını azaltır; pratikte commit latency p99’unu %20-40 düşürür. NVMe + Linux 6.x üzerinde vm.dirty_background_ratio=5, vm.dirty_ratio=10, vm.dirty_expire_centisecs=3000 Postgres ile uyumlu klasik OS ayarlarıdır.

4. Autovacuum: Bloat’un Sessiz Düşmanı

Autovacuum kapatılırsa ya da yetersiz çalışırsa tablo ve index bloat’u büyür, plan cost’u bozulur, sequential scan rastgele tetiklenir. PostgreSQL’in MVCC modeli her UPDATE’i yeni satır yaratıp eskisini “dead tuple” yapar; bu dead tuple’ları autovacuum temizler. Yüksek write hızında default ayarlar yetersizdir.

Önerilen tabloda ölçek bazlı ayarlar:

Parametre	Default	Üretim Önerisi	Açıklama
autovacuum_max_workers	3	6-8	Çok tablolu OLTP’de paralel temizlik
autovacuum_naptime	60s	15-30s	Worker’ların döngü sıklığı
autovacuum_vacuum_scale_factor	0.2	0.05	%5 ölü tuple’da tetikle
autovacuum_vacuum_threshold	50	500	Mikro tabloyu durdurma
autovacuum_analyze_scale_factor	0.1	0.02	Plan istatistikleri daha sık güncel
autovacuum_vacuum_cost_limit	200	2000-4000	NVMe’de I/O bütçesini aç
maintenance_work_mem	64 MB	1-8 GB	Index rebuild ve vacuum hızı

Büyük (10+ milyar satır) tablolarda tablo-bazlı override kritik:

ALTER TABLE orders SET (
  autovacuum_vacuum_scale_factor = 0.01,
  autovacuum_vacuum_cost_limit = 4000,
  autovacuum_analyze_scale_factor = 0.005,
  fillfactor = 90
);

fillfactor=90 HOT update oranını artırır; index bloat’unu yavaşlatır. Bu tarz operasyonel tedbirler bir veri platformunun temel sağlığı için “DBA hijyeni” sayılır; mimari plana veri yönetişimi ve katalog politikalarıyla beraber işlenmeli.

5. Connection Pool: PgBouncer ve max_connections

Postgres’in en çok yanlış konfigüre edilen parametresi max_connections‘tır. Her connection ~10 MB RAM + planner overhead + lock manager slot’u tüketir. 2000 connection açmak 20 GB RAM “vergi”si demek; üstelik concurrent active query sayısı CPU çekirdek sayısının 2-3 katını geçtiğinde context-switch maliyeti throughput’u düşürür.

Standart yaklaşım: max_connections=200-400 + PgBouncer transaction pooling. App tarafında 5000 bağlantı isteğini, DB tarafında 200 fiziksel session’a sıkıştırır.

Konfigürasyon	Tipik TPS	p99 Latency	RAM Maliyeti	Notlar
Doğrudan, max_connections=1000	~8.000	120 ms	~10 GB	Context switch baskısı
Doğrudan, max_connections=300	~14.000	45 ms	~3 GB	App’te kuyruk olur
PgBouncer transaction, 300 DB / 5000 client	~22.000	28 ms	~3 GB	Çoğu OLTP için optimum
PgBouncer session, 1000 DB / 5000 client	~12.000	80 ms	~10 GB	Prepared stmt uyumu
PgCat / Supavisor	~25.000	26 ms	~3 GB	Modern alternatif, shard farkındalığı

Önemli not: PgBouncer transaction pooling ile SET, advisory lock, prepared statement gibi session-bağımlı feature’lar çalışmaz; app kodu transaction-local olmak zorunda. Buna karşılık latency ve throughput kazancı çoğu workload’da bu kısıtlamayı tolere edilebilir kılar.

6. Planner Tuning: random_page_cost, work_mem ve İstatistikler

Query planner’ın kararını üç parametre çok etkiler: random_page_cost, seq_page_cost ve effective_cache_size. NVMe SSD üzerinde random ve sequential read maliyeti neredeyse eşit. Default random_page_cost=4.0 HDD çağından kalmadır; SSD’de 1.1-1.5 üretim referansıdır. Bu değişiklik tek başına büyük tablolarda index scan tercih oranını artırır ve p95 latency’yi %20-35 düşürür.

work_mem ise per-operation (per-sort, per-hash). 32 paralel sort yapan bir query work_mem=128MB ile 4 GB RAM yiyebilir. Global ayarı düşük tut (32-128 MB), büyük analytic query’lerde session bazlı yükselt:

SET LOCAL work_mem = '512MB';
SELECT ... FROM big_fact JOIN big_dim ...;

İstatistik kalitesi planner’ın temelidir. default_statistics_target=100 defaultu çoğu OLTP’de yetersiz; 250-500 aralığı büyük tablolarda histogramı zenginleştirir. ANALYZE sonrası p99 plan stabilitesi belirgin artar. Daha ileri seviyede dbt analytics engineering akışlarındaki test ve transformasyon katmanı, planner istatistiklerini bozmadan modellemenin kapısını açar.

7. Storage, Filesystem ve OS Kernel Ayarları

Postgres’in performansı disk seçimine ekstrem hassastır. NVMe Gen4 SSD üzerinde sıralı okuma 7 GB/s, rastgele 4K okuma 1M IOPS’a yakındır; aynı workload SATA SSD’de yaklaşık 550 MB/s ve 90-100K IOPS’ta sınırlıdır.

Filesystem tarafında ext4 ve XFS üretimde tercih edilir; ZFS özel ihtiyaç (snapshot, ARC) varsa. Mount option olarak noatime,nodiratime standart; XFS’de logbsize=256k yazma latency’sini iyileştirir. Linux scheduler için NVMe’de none veya mq-deadline; rotational disk için bfq.

1. Transparent Huge Pages (THP): asla “always” bırakma. echo madvise > /sys/kernel/mm/transparent_hugepage/enabled. THP “always” Postgres’te 100-300 ms stall spike’larına yol açar.
2. vm.swappiness: 1-10 arası. Postgres swap’a düşmemeli.
3. vm.overcommit_memory: 2 ve vm.overcommit_ratio=80. OOM-killer’ın Postgres’i öldürmesini önler.
4. HugePages: shared_buffers büyükse (>8 GB) explicit hugepages açılması TLB miss’i azaltır, %3-7 throughput verir.
5. I/O readahead: NVMe için blockdev --setra 256 yeterli; spinning disk’te 4096.
6. Filesystem barrier: kapatma. Postgres kendi fsync semantiğini yönetir; modern FS’lerde barrier default açık ve bırakılmalı.

8. Replikasyon, HA ve synchronous_commit Trade-off’u

Streaming replication, PostgreSQL’in lider HA yöntemi. Patroni + etcd + HAProxy stack’i 2025-2026’da CNCF Landscape’inde de yer alıyor ve fintech’ten e-ticarete kadar üretimde standart kabul edilir. Replikasyon performansını ve dayanıklılığını belirleyen üç parametre: synchronous_commit, synchronous_standby_names, wal_sender_timeout.

Mod	Anlam	Veri Kaybı Riski	Commit Latency Ek Yükü
off	WAL fsync yok	Yüksek (son birkaç tx)	~0 (en hızlı)
local	Sadece local WAL fsync	Lokal’de yok, replicada olası	+düşük
remote_write	Standby OS cache yazdı	Çift node crash’te	+0.5-2 ms
on (default)	Standby WAL flush etti	Çok düşük	+1-3 ms
remote_apply	Standby uyguladı	En düşük	+5-15 ms

Finansal işlem hattında remote_apply gerekli olabilir; ürün katalog güncellemesi için remote_write yeterli. Tek bir global ayar yerine business-criticality bazlı per-transaction SET LOCAL synchronous_commit = 'remote_apply' yaklaşımı modern dizayn. Bu seçim doğrudan downstream pipeline’a, örneğin stream processing Flink Kafka ile beslenen analitik tarafa kadar uzanan tutarlılık sözleşmesini şekillendirir.

9. Gözlemlenebilirlik: pg_stat_statements ve OpenTelemetry

Tuning bilimi değil mühendisliktir; her parametre değişikliği ölçülmeli. pg_stat_statements extension’ı en kritik gözlem aracıdır; query bazlı toplam zaman, çağrı sayısı, I/O ve plan sayısını verir.

• pg_stat_statements: shared_preload_libraries='pg_stat_statements', pg_stat_statements.max=10000, pg_stat_statements.track=all. Avantaj: top N pahalı query’yi 5 dakikada bulursun. Dezavantaj: ~%1-3 CPU overhead.
• auto_explain: auto_explain.log_min_duration=500ms. Yavaş query’lerin planını otomatik loglar.
• pg_stat_kcache / pg_stat_io: PG 16+ pg_stat_io ile per-backend I/O görünür.
• OpenTelemetry collector: Postgres exporter ile Prometheus + Grafana entegrasyonu; CNCF standardı.
• pgBadger: CSV log analizi; slow query report’u günlük tetikle.

Production’daki Postgres’i gözlemlemeden tune etmek, Ömer Önal’ın yıllardır verdiği danışmanlık deneyiminde gördüğü en yaygın hatadır: parametreyi değiştir, “iyi oldu sanki” hissiyatıyla bırak. Oysa pg_stat_statements‘in total_exec_time, mean_exec_time ve shared_blks_hit/read oranları somut karar verdirir.

Gözlemlenebilirlik yığını büyük ölçekte Big Data Spark Kafka pipeline tarafıyla da uyumlu çalışır; Postgres metrikleri Kafka üzerinden bir lakehouse’a (örnek Databricks/Snowflake mimarisi) akarak haftalık tuning retrospektifi için zemin oluşturur.

10. Üretim Konfigürasyonu Şablonu (64 GB, NVMe, OLTP)

Tek bir konfigürasyon “tüm Postgres’lere yeter” demek mümkün değil; ama 64 GB RAM, 16 vCPU, NVMe SSD, OLTP-ağırlıklı bir node için aşağıdaki şablon kanıtlanmış bir başlangıçtır. Test ortamında pgbench -c 64 -j 16 -T 600 ile doğrulanmalı.

# Memory
shared_buffers = 16GB
effective_cache_size = 48GB
work_mem = 64MB
maintenance_work_mem = 4GB
huge_pages = try

# WAL
wal_level = replica
max_wal_size = 16GB
min_wal_size = 4GB
wal_compression = zstd
wal_buffers = 64MB
synchronous_commit = on
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9

# Planner
random_page_cost = 1.1
seq_page_cost = 1.0
effective_io_concurrency = 256
default_statistics_target = 250

# Connections
max_connections = 300
# Pool: PgBouncer transaction, 5000 client -> 300 DB

# Autovacuum
autovacuum_max_workers = 8
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02
autovacuum_vacuum_cost_limit = 3000

# Observability
shared_preload_libraries = 'pg_stat_statements, auto_explain'
pg_stat_statements.track = all
auto_explain.log_min_duration = 500ms
log_min_duration_statement = 1000ms
log_checkpoints = on
log_lock_waits = on
log_temp_files = 0

Bu şablon üzerinden değişiklik yaparken her seferinde tek parametre ilkesi geçerlidir; aksi halde hangi ayarın hangi metriği değiştirdiği bilinemez. Şablonu büyük tabloları olan, yüksek concurrency’li bir vektör veritabanı karşılaştırması içeren bir hibrit iş yüküne uyarlarken shared_buffers oranını korurken maintenance_work_mem‘i 8 GB’a, max_parallel_workers‘ı 16’ya çıkartmak tipik bir adımdır.

11. Sık Sorulan Sorular

12. Sonuç

PostgreSQL tuning, donanım, workload ve uygulama kodu birlikte ele alınmadan yapılabilecek bir iş değildir. shared_buffers, WAL ve autovacuum üçgenini doğru oturtmak — RAM’in %25’i shared_buffers, max_wal_size 16 GB, checkpoint_timeout 15 dakika, autovacuum_vacuum_scale_factor 0.05, random_page_cost 1.1 gibi kanıtlanmış başlangıç noktaları — sistemin temel sağlığını verir. Üstüne PgBouncer ile bağlantı disiplini, pg_stat_statements ile gözlemlenebilirlik ve THP/swappiness gibi OS-katmanı hijyeni eklendiğinde, p99 latency’nin yarılandığı ve throughput’un iki katına çıktığı senaryolar gerçekten istisna değil norm haline gelir.

Karar çerçevesi şu üç soru üzerinden ilerler: (1) İş yükü OLTP mı, OLAP mı, karma mı? (2) Donanım NVMe + 64 GB+ RAM mi, yoksa cloud managed (RDS, Cloud SQL, Azure Database) mu? (3) Tutarlılık ihtiyacı hangi seviyede — local fsync mi, remote_apply mı? Bu üç soruya net cevap verildiğinde yukarıdaki şablon büyük ölçüde değiştirilmeden uygulanabilir; ayrımlar parametre seviyesinde, mimari seviyesinde değildir.

İlk 30 günde uygulanması önerilen “Postgres tuning operasyonel checklist’i”:

• Gün 1-3: pg_stat_statements ve auto_explain aç, baseline metrikleri Grafana’ya çek. Avantaj: Sonraki tüm değişiklikleri ölçülebilir hale getirir.
• Gün 4-10: shared_buffers, effective_cache_size, work_mem’i donanıma uygun değerlere çek; her değişiklik sonrası 24 saat gözlem. Ne zaman dur: p99 latency veya cache hit oranı kötüleşirse geri al.
• Gün 11-20: WAL ve checkpoint katmanını ayarla (max_wal_size, checkpoint_timeout, wal_compression=zstd). Dezavantaj: max_wal_size artarsa crash recovery süresi de artar; HA senaryosunda hesaba kat.
• Gün 21-25: PgBouncer transaction pooling devreye al, max_connections’ı 300’e indir. Uygulamayı session-state’ten arındır.
• Gün 26-30: autovacuum agresifleştir, kritik tablolara per-table override yaz, OS katmanında THP ve swappiness ayarla. Sonuç: baseline’a göre p99 latency’de %30-50, throughput’ta %40-80 iyileşme tipik aralıktır.

Postgres tuning’i tek seferlik bir iş olarak görmek yerine sürekli ölçülen, kademeli iyileştirilen bir mühendislik akışı olarak ele almak gerekir; ekibinizin bu döngüyü kurmasında dış göz veya yapısal destek gerekiyorsa iletişim sayfası üzerinden danışmanlık talebi oluşturabilir, mevcut konfigürasyonunuzun ve workload profilinizin bağımsız bir incelemesini başlatabilirsiniz.

Kaynaklar ve referanslar: PostgreSQL official docs — Resource Configuration, PostgreSQL WAL Configuration, PgBouncer Configuration Reference, Stack Overflow Developer Survey 2024 — Databases, AWS RDS PostgreSQL Best Practices, Patroni — High Availability for PostgreSQL, CNCF Landscape — Database & Observability projects.