#1. Yönetici Özeti ve Problem Tanımı

İlişkisel veritabanları (PostgreSQL, MySQL, Aurora) genellikle bir bulut dağıtımındaki tek başına en pahalı kalıcı servistir. Performans düştüğünde, mühendislik ekipleri genellikle dikey sunucu büyütmeye (örneğin db.r6g.xlarge'dan db.r6g.4xlarge'a geçerek aylık maliyeti $1.800/ay düzeyine çıkarma) başvurur.

Olayların $\%80$'inden fazlasında veritabanı CPU doygunluğu gerçek iş hacminden değil, şunlardan kaynaklanır:

1. İstek başına milyonlarca satırı tarayan indekssiz yavaş sorgular.
2. Mikroservislerin havuzsuz doğrudan bağlantı açması nedeniyle oluşan bağlantı tükenmesi.
3. Düşük trafikli saatlerde boşta bekleyen aşırı tahsis edilmiş okuma kopyaları (read-replicas).

---

#2. PgBouncer ile Bağlantı Havuzu Mimarisi

Her PostgreSQL bağlantısı 5 MB ila 10 MB ayrılmış sunucu belleği tüketir ve çekirdek süreç zamanlama yükü getirir. Yüksek eşzamanlılık altında 500 doğrudan istemci bağlantısı 4 GB bellek harcayabilir ve CPU zamanlamasını kilitleyebilir.

PgBouncer'ı işlem havuzu (transaction pooling) modunda dağıtmak, 10.000 uygulama istemcisinin 50 arka uç veritabanı bağlantısını sorunsuzca paylaşmasını sağlar:

[1.000 Mikroservis Pod'u] ──> [PgBouncer Havuzlayıcı] ──> [50 Özel PG Bağlantısı] ──> [RDS Postgres]

PgBouncer Canlı Ortam Yapılandırması

[databases]
app_db = host=aurora-cluster.prod.internal port=5432 dbname=app_production pool_mode=transaction

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = scram-sha-256
max_client_conn = 5000
default_pool_size = 50
reserve_pool_size = 10
server_idle_timeout = 60

---

#3. CPU'yu Kilitleyen Sorguları Tespit Etmek ve İyileştirmek

CPU zamanının büyük çoğunluğunu tüketen ilk 5 sorguyu belirlemek için pg_stat_statements eklentisini çalıştırın:

SELECT 
    round((total_exec_time / 1000 / 60)::numeric, 2) AS total_minutes,
    calls,
    round((mean_exec_time)::numeric, 2) AS avg_ms,
    round((100 * total_exec_time / sum(total_exec_time) OVER ())::numeric, 2) AS percentage_cpu,
    query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 5;

Toplam CPU süresinin %90'ını alan sorgulara tek bir bileşik indeks (composite index) eklemek, genellikle veritabanı CPU kullanımını %95'ten %8'e düşürür ve sunucunun derhal küçültülmesine imkan tanır.

---

#4. Sunucusuz Veritabanı Ölçekleme Tavanları

Sunucusuz veritabanları için (AWS Aurora Serverless v2, Neon):

• Her zaman katı bir max_capacity tavanı tanımlayın (örneğin canlıda azami 8 ACU, hazırlıkta 2 ACU).
• Tavan sınır olmaksızın, bir toplu veri yükleme görevi veya özyinelemeli bir sorgu 128 ACU'ya kadar tam ölçeklenmeyi tetikleyebilir ve saatler içinde binlerce dolarlık sürpriz faturalar üretebilir.