Yavaş database'e donanım atmak en pahalı çözümdür
Database performans sorunları genellikle yazılımda (sorgular, indeksler, schema) donanımdan (daha büyük instance, daha fazla bellek) çok daha ucuza düzeltilebilir.EXPLAIN, sonra EXPLAIN ANALYZE
Her yavaş sorgu başka bir eylem öncesi EXPLAIN'lenir.Aranacak:
- Büyük tabloda sequential scan — genellikle eksik indeks.
- Büyük tablolarda nested loop — kötü join sırası.
- Büyük satır taramalı Sort + Limit deseni.
- Disk'e dökülen hashtable ile hash join — work_mem çok küçük.
- Bitmap heap scan.
Indeksler — doğruları, hepsi değil
- B-tree — varsayılan. Equality ve range için.
- Composite — multi-column. Sıra önemli.
- Partial — predicate eşleşen satırları indeksle.
- Expression — kolon fonksiyonu indeksi.
- GIN / GIST — full-text, JSONB, geospatial için.
Indekslerin maliyeti
Indeksler okumayı hızlandırır, yazmayı yavaşlatır. Sorgu başına bir indeks ekleyen ekip write-bottleneck biriktirir.Karşılığını veren sorgu desenleri
- ORDER BY ile LIMIT indeks kullanır.
- "Eşleşen herhangi bir satır" için IN yerine EXISTS.
- SELECT *'tan kaçının.
- Büyük veri setlerinde OFFSET'ten kaçının — cursor tabanlı pagination kullanın.
- Prepared statement'lar kullanın.
- Batch INSERT'lar.
- Bulk yüklemeler için COPY.
N+1 sorguları
Uygulama öğe listesi yükler, sonra her öğe için ayrı sorgu yapar. 1 JOIN'lu sorgu yerine 1+N sorgu.Düzeltme uygulama düzeyinde (eager loading, JOIN, child sorgu batch).
Cache hit oranları
Postgres için:- Buffer cache hit oranı — sağlıklı OLTP'de >%99 olmalı.
- Index cache hit oranı — aynı hedef.
Locking ve contention
- Yavaş sorgu log'unda lock waits = contention.
- Uzun süren transaction'lar lock tutar.
- Update-ağır hotspot'lar → farklı tasarım düşünün.
Vacuum ve bloat
Postgres için:- Vacuum dead tuple'lardan alan geri alır.
- Autovacuum varsayılan açık.
- Bloat — pg_repack veya VACUUM FULL.
Bağlantı maliyetleri
- Connection pooling (Postgres için pgBouncer).
- Uygulama bağlantı havuzları gerçekçi eş zamanlı aktif sorgulara göre boyutlandırılır.
Donanım son kaldıraç olarak
- Daha fazla RAM.
- Daha hızlı diskler (NVMe).
- Daha fazla CPU.
Deneyimimize göre, "database yavaş" sorunlarının ~%80'i yazılım katmanında çözülür.
Uyaracağımız bir desen
"Daha çok indeks = daha hızlı sorgu" diye kör indeks ekleme.Her zaman karşılığını veren bir desen
Haftalık yavaş-sorgu incelemesi.Gönderdiğiniz en şaşırtıcı performans düzeltmesi nedir?
Throwing hardware at a slow database is the most expensive solution
Database performance issues are usually fixable in software far cheaper than in hardware.EXPLAIN, then EXPLAIN ANALYZE
Every slow query gets EXPLAIN'd before any other action.What to look for:
- Sequential scan on a large table — usually missing index.
- Nested loop on big tables — poor join order.
- Sort + Limit with large rows scanned.
- Hash join with hashtable spilling — work_mem too small.
- Bitmap heap scan.
Indexes — the right ones
- B-tree — default.
- Composite — multi-column. Order matters.
- Partial — index only rows matching a predicate.
- Expression — index on function of a column.
- GIN/GIST — for full-text, JSONB, geospatial.
The cost of indexes
Indexes speed reads and slow writes.Query patterns that help
- LIMIT with ORDER BY uses indexes.
- EXISTS over IN.
- Avoid SELECT *.
- Avoid OFFSET on large datasets.
- Use prepared statements.
- Batch INSERTs.
- COPY for bulk loads.
N+1 queries
The application loads a list, then makes a separate query per item. Fix at application level.Cache hit ratios
For Postgres:- Buffer cache hit ratio — >99% on healthy OLTP.
- Index cache hit ratio — same target.
Locking and contention
- Lock waits = contention.
- Long transactions hold locks.
- Update-heavy hotspots → different design.
Vacuum and bloat
For Postgres:- Vacuum reclaims dead tuple space.
- Autovacuum on by default.
- Bloat — pg_repack or VACUUM FULL.
Connection costs
- Connection pooling (pgBouncer).
- Pools sized for realistic concurrent queries.
Hardware as last lever
- More RAM.
- Faster disks (NVMe).
- More CPU.
~80% of "slow database" issues resolve at software layer.
One pattern we'd warn about
Adding indexes blindly.One pattern that always pays off
A weekly slow-query review.What's the most surprising performance fix you've shipped?
