sade.dev — PostgreSQL Üretimde

pgBouncer auth_query ile Çoklu DB Kullanıcısı

info@muhammetsafak.com.tr (Muhammet Şafak) — Sun, 19 Apr 2026 00:00:00 GMT

pgBouncer connection pooler olarak harika; ancak default yapılandırması bir düşmanlığı kabul ediyor: kullanıcı listenizi manuel olarak userlist.txt’ye yazmak zorundasınız. Her yeni DB kullanıcısı eklediğinizde dosyayı güncellemek, hash’i hesaplamak, pgBouncer’ı reload etmek. Operasyonel bir baş ağrısı.

auth_query bunu çözüyor: pgBouncer doğrulama için PostgreSQL’in kendisine sorgu atıyor.

auth_user kurulumu

PostgreSQL tarafında düşük yetkili bir kullanıcı ve pg_shadow’u okuyan bir fonksiyon oluşturuyoruz:

CREATE ROLE pgbouncer LOGIN PASSWORD 's3cr€t_p@ssw0rd';

CREATE SCHEMA pgbouncer;
GRANT USAGE ON SCHEMA pgbouncer TO pgbouncer;

CREATE OR REPLACE FUNCTION pgbouncer.user_lookup(in i_username text,
                                                 out uname text,
                                                 out phash text)
RETURNS record AS $$
BEGIN
    SELECT usename, passwd FROM pg_catalog.pg_shadow
    WHERE usename = i_username INTO uname, phash;
    RETURN;
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

REVOKE ALL ON FUNCTION pgbouncer.user_lookup(text) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION pgbouncer.user_lookup(text) TO pgbouncer;

SECURITY DEFINER önemli — fonksiyon pg_shadow’a erişim için tanımlayan kullanıcının yetkilerini kullanıyor. Aksi takdirde pgbouncer rolü pg_shadow’u okuyamaz.

auth_query hedef veritabanının içinde çalışır; bu yüzden fonksiyonu pgBouncer’ın hizmet vereceği her veritabanına kurmanız gerekir.

pgBouncer config

pgbouncer.ini:

[databases]
* = host=127.0.0.1 port=5432

[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 6432

auth_type = scram-sha-256
auth_user = pgbouncer
auth_query = SELECT uname, phash FROM pgbouncer.user_lookup($1)

pool_mode = transaction
max_client_conn = 1000
default_pool_size = 25

Artık userlist.txt yok. PostgreSQL’de yeni bir rol oluştursanız, pgBouncer restart’ı gerektirmeden doğrulama çalışıyor.

md5 mi, scram-sha-256 mı?

PostgreSQL 14+ default olarak scram-sha-256 kullanıyor. pgBouncer bunu 1.11’den beri destekliyor; auth_query ile SCRAM pass-through ise 1.14 ile geldi. Eski cluster’larda md5’e düşmek zorunda kalıyorsanız:

auth_type = md5

Ama yeni kurulum yapıyorsanız scram-sha-256 kullanın — md5 artık zayıf.

Hangi pool mode seçilmeli?

Üç mod var, çoğu Laravel/Django uygulaması için tercih:

session — bağlantı baştan sona aynı. Prepared statement’lar çalışır, ama pool faydası zayıf.
transaction — her transaction sonunda bağlantı serbest. En yaygın tercih. Protokol düzeyi prepared statement’lar 1.21+ gerektiriyor; 1.24’ten beri varsayılan olarak açık (max_prepared_statements = 200).
statement — her query sonunda. Çoğu ORM ile sorunlu.

Pratik: transaction’la başlayın, sorun yaşarsanız session’a geçin.

Yaygın hata: read-only role’ün password’ü yok

auth_query pg_shadow.passwd’i okuyor. Eğer kullanıcı SSO ile geliyorsa veya peer authentication kullanıyorsa, passwd alanı NULL’dur — pgBouncer login’i reddeder. Bu durumda pg_hba.conf üzerinden trust veya peer kurmak gerekir, ama production’da bunu istemezsiniz.

İzleme

pgBouncer kendi admin DB’sini sağlıyor:

psql -p 6432 pgbouncer -U pgbouncer
> SHOW POOLS;
> SHOW STATS;
> SHOW CLIENTS;

cl_waiting > 0 görüyorsanız default_pool_size’ı arttırmak gerekiyor olabilir. sv_idle çok yüksekse tam tersi — pool overprovision’da.

pgBackRest ile PostgreSQL Backup Stratejisi

info@muhammetsafak.com.tr (Muhammet Şafak) — Fri, 08 May 2026 00:00:00 GMT

pg_dump ile uğraşmayı bıraktığım gün, sistem yazılım mühendisi olarak ciddiyetimin arttığını düşünüyorum. pg_dump bir araştırma aracı — production yedek aracı değil.

Üretim yedeği üç şeyi sağlamalı:

Point-in-time recovery (PITR). “Dün gece 02:13’te silindi” diyebilmek.
Bütünlük doğrulaması. Yedek dosyasının açıldığında çalıştığını test etmek.
Saklamayı politikayla yönetmek. 6 saatlik/günlük/haftalık rotasyon.

pg_dump üç maddeyi de karşılamıyor.

pgBackRest kurulumu

Ben hem yerel hem de S3 yedeği almayı tercih ve tavsiye ediyorum. Yerel yedekler hızlı, S3 yedekleri ise yangına dayanıklı.

Off-site kopya

Repository tek bir diskte duruyorsa bir VPS yangını her şeyi siler. pgBackRest S3 veya S3-uyumlu (R2, MinIO) bucket’a yazabiliyor:

Tercih: bucket’ı versiyon-kilitli ve delete’i yasaklayan bir policy ile koruyun. Ransomware senaryosunda kritik.

Maliyetleri uzun vadeli kontrol altında tutmak için bucket yaşam döngüsünü ayarlayın:

30 Gün → Glacier Anında Alma → 120 Gün → Sil

/etc/pgbackrest.conf:

[global]

###################################
# Local Repository
###################################
repo1-path=/var/lib/pgbackrest
repo1-retention-full=4
repo1-retention-diff=14
repo1-bundle=y
repo1-block=y
repo1-cipher-pass=...
repo1-cipher-type=aes-256-cbc

###################################
# AWS S3 Repository
###################################
repo2-type=s3
repo2-path=/main
repo2-s3-bucket=...
repo2-s3-endpoint=s3.{region_name}.amazonaws.com
repo2-s3-region={region_name}
repo2-s3-key=...
repo2-s3-key-secret=...
repo2-bundle=y
repo2-block=y
repo2-cipher-type=aes-256-cbc
repo2-cipher-pass=...

###################################
compress-type=zst
compress-level=6
process-max=4
start-fast=y
log-level-console=info
log-level-file=detail
log-path=/var/log/pgbackrest

[main]
pg1-path=/var/lib/postgresql/16/main
pg1-port=5432

Yetkileri sıkılaştırın:

sudo chown postgres:postgres /etc/pgbackrest.conf
sudo chmod 640 /etc/pgbackrest.conf

Stanza oluşturun:

sudo -u postgres pgbackrest --stanza=main stanza-create

postgresql.conf tarafında ise WAL archiving’i pgBackRest’e yönlendiriyoruz:

archive_mode = on
archive_command = 'pgbackrest --stanza=main archive-push %p'
archive_timeout = 60
wal_level = replica

archive_timeout = 60 — son 60 saniyenin işlemleri kaybedilebilir; çoğu uygulama için yeterli, finansal işlemler için değil.

Backup planı

Cron tarafında:

# Yerel repository (repo1)
0 2 * * 0          pgbackrest --stanza=main --repo=1 --type=full backup
0 2 * * 1-6        pgbackrest --stanza=main --repo=1 --type=diff backup
0 0,6,12,18 * * *  pgbackrest --stanza=main --repo=1 --type=incr backup

# S3 repository (repo2)
0 4 * * 0          pgbackrest --stanza=main --repo=2 --type=full backup
0 4 * * 1-6        pgbackrest --stanza=main --repo=2 --type=diff backup
0 3,9,15,21 * * *  pgbackrest --stanza=main --repo=2 --type=incr backup

İki repo yapılandırıldığında --repo şart: verilmezse pgBackRest yalnızca en yüksek öncelikli repoya (repo1) yedek alır, S3’te arşivlenen WAL’dan başka bir şey durmaz — tek başına restore edilemeyen bir kopya.

Her repoda haftalık full, günlük diff, 6 saatlik incremental. Storage tüketimi şaşırtıcı derecede düşük — konfigürasyondaki repoN-bundle/repoN-block satırları block incremental yedeği açıyor, böylece pgBackRest dosyanın tamamını değil yalnızca değişen bloklarını kopyalıyor; ikisi de varsayılanda kapalı.

Bütünlük: yedek varsa restore edilebilir mi?

Yedeği almak yeterli değil. Haftada bir restore tatbikatı:

pgbackrest --stanza=main --delta restore --pg1-path=/tmp/pg_restore_test

Sonra o instance’ı geçici bir port üzerinde başlatıp birkaç sanity query çalıştırıyorum. Bu adım atlanırsa yedek sahte güven olur.

PITR provası

Belirli bir zamana geri dönmek:

pgbackrest --stanza=main \
  --type=time \
  --target='2026-05-07 02:13:00+03' \
  restore

Bu komutun gerçek bir incident’te ilk kez çalıştırılması felakettir. Provayı önceden yapın — adımlar runbook’a yazılsın.

Saklama

Repository’deki kullanılmayan yedeklerin temizliği expire komutuyla:

pgbackrest --stanza=main expire

repo1-retention-full=4 ile son 4 full yedek tutuluyor; daha eskileri (ve onlara bağlı diff/incr’ler) otomatik temizleniyor.

Sonuç

Schema kopyalamak veya küçük bir tabloyu taşımak için pg_dump hâlâ doğru araç. Ama PITR isteyen herhangi bir sistemde yedek yazılımı pgBackRest (veya barman, ya da veritabanı sağlayıcının kendi aracı) olmalı. Backup’ın test edilmediği anda “backup’ım var” demek yalan söylemenin sofistike bir yoludur.

Read/Write Splitting: Okuma ve Yazma Yükünü Ayırmak

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 22 Aug 2026 00:00:00 GMT

Primary veritabanının CPU’su sürekli tavandaydı. İlginç olan şuydu: yazma oranı düşüktü. Yükün neredeyse tamamı okumaydı — rapor sayfaları, listeleme endpoint’leri, arama. Tek bir primary, kendisine hiç ihtiyaç duymayan bir sürü okumayı taşımaya çalışıyordu.

Okuma ve yazma yükünü ayırmak — read/write splitting — bu tablonun bilinen çözümü. Ama doğru zamanda ve doğru tuzakların farkında uygulanmazsa, çözdüğünden çok problem getirir.

Çoğu yük okuma ağırlıklıdır

Trafiğin ne kadarının okuma olduğu iş yüküne bağlıdır: standart OLTP benchmark’larının ölçümünde TPC-E %90,69 okumadır, TPC-C ise %65,71’de kalır — yani kendi oranınızı varsaymak yerine ölçün. Her sipariş bir kez yazılır, ama onlarca kez okunur: listede, detayda, raporda, panelde. Bu asimetri, read/write splitting’i cazip kılan şeydir — çünkü ölçeklemeniz gereken taraf bellidir.

Önce: bu gerçekten bir kapasite sorunu mu?

Replica eklemeden önce durun. Primary’nin dolu olması her zaman “kapasite bitti” demek değildir. Çoğu zaman tek bir eksik indeks, primary’yi olduğundan kat kat meşgul gösterir.

Bir replica eklemek — yeni bir sunucu, replication kurulumu, lag izleme — aslında bir CREATE INDEX’in çözeceği bir problemi pahalıya satın almak olabilir. Veri yoğunluklu sistemlerin kırılma noktaları yazısındaki sıra nettir: önce indeks disiplini, sonra replica. Bu sırayı atlamayın.

Sorgularınızı EXPLAIN ANALYZE ile ölçün. Primary, doğru indekslenmiş sorgular altında gerçekten doyuyorsa — işte o zaman replica.

Replica okumayı ölçekler, yazmayı değil

Net olalım: bir read replica, yazma kapasitenize hiçbir şey katmaz. Aynı yazmalar her replica’da yeniden oynanır. Replica okuma yükü problemini çözer; yazma yükü probleminiz varsa replica yanlış araçtır.

Laravel’de kurulum

Laravel, okuma/yazma bağlantı ayrımını doğal destekler:

// config/database.php
'pgsql' => [
    'driver' => 'pgsql',
    'read'   => ['host' => ['10.0.0.2']],   // replica
    'write'  => ['host' => ['10.0.0.1']],   // primary
    'sticky' => true,
    // ...ortak ayarlar
],

SELECT’ler replica’ya, INSERT/UPDATE/DELETE’ler primary’ye gider. Replica’nın kendi bağlantı havuzu olur — primary’ninkinden ayrı; pgBouncer kullanıyorsanız ikisi ayrı havuzdur.

Replication lag: asıl fatura

Replica, primary’nin birkaç milisaniye — yük altında birkaç saniye — gerisindedir. Bu gecikme, read/write splitting’in gerçek bedelidir ve adı read-after-write problemidir.

sticky => true bunu kısmen çözer: bir istek içinde yazma yaptıysanız, aynı istekteki sonraki okumalar primary’ye gider. Ama sticky yalnızca tek bir istek sınırında çalışır.

Sınırın dışı hâlâ açıktır: kullanıcı profilini günceller (istek 1, primary’ye yazıldı), sonraki sayfaya geçer (istek 2, replica’dan okur) ve henüz replica’da oynanmamış eski profilini görür. Kullanıcı kendi yazdığı veriyi bayat görür. Bu bir bug gibi görünür ama aslında mimarinin kabul ettiği bir ödündür — bilerek kabul edilmesi gereken bir ödün.

Sorgu sınıflandırma disiplini

Read/write splitting’i kurmak, her okumanın şu soruya cevap vermesini gerektirir: bu sorgu bayat veri okuyabilir mi?

Replica’dan okunabilir: listeler, raporlar, arama sonuçları, paneller. Birkaç saniye gecikme önemsiz.
Primary’den okunmalı: hesap bakiyesi, stok adedi, yetki kontrolü, bir yazma kararının dayandığı her okuma.

Bu sınıflandırma artık mimarinin bir parçasıdır ve dokümante edilmesi gerekir. Yeni gelen bir geliştiricinin “bu sorgu nereden okumalı” sorusuna bakacak bir yeri olmalı — yoksa sınıflandırma sessizce çürür.

Ne zaman gerçekten gerekir?

Read/write splitting şu üç koşul birlikte sağlandığında doğru hamledir:

İndeks disiplini tamamlanmış; sorgular doğru indeksli ve hâlâ primary doyuyor.
Yük ölçülmüş biçimde okuma ağırlıklı.
Bayat-okuma sınıflandırmasını yapıp dokümante edecek disiplin var.

Bunlardan biri eksikse, replica’yı ertelemek daha ucuzdur.

Read/write splitting, dikey büyümeden ucuz bir ölçek hamlesidir — ama bedava değildir. Bedeli replication lag’dir ve onu görmezden gelmek, kullanıcıya kendi verisini eski göstermekle ödenir.

Okumayı ayırmadan önce, hangi okumanın bayatlığa dayanabileceğini bilin.

Canlıda Sıfır Kesintiyle Şema Değiştirmek

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 29 Aug 2026 00:00:00 GMT

Bir deploy, 50 milyon satırlık bir tabloda tek bir ALTER TABLE çalıştırdı ve tabloyu dört dakika kilitledi. Dört dakika boyunca o tabloya değen her istek bekledi; site fiilen çöktü. Migration’ın kendisi doğruydu — sorun, onun tek adımda yapılmasıydı.

Tehlikeli olan şema değişikliği değildir. Tehlikeli olan, şema değişikliğini tek seferde, geri uyumluluğu düşünmeden yapmaktır.

Lock’u kim alır?

Her şema değişikliği aynı maliyette değildir. Modern PostgreSQL’de sabit DEFAULT ile kolon eklemek bir metadata işlemidir — hızlıdır. Asıl tehlike, tabloyu uzun süre kilitleyen işlemlerdedir:

CREATE INDEX — CONCURRENTLY olmadan tabloyu yazmaya kapatır.
Tabloyu yeniden yazan ALTER COLUMN ... TYPE değişiklikleri.
Tüm tabloyu tarayan NOT NULL, CHECK veya foreign key eklemeleri.

Bu işlemler güçlü bir lock alır; ACCESS EXCLUSIVE alanlar — tablo yeniden yazımı ya da NOT NULL/CHECK eklemesi — tabloya değen her sorguyu, okuma dahil, kuyruğa sokar. Geri kalanı yalnızca yazmaları bloklar. Tablo büyükse kuyruk uzar.

Tehlikeli olan tek adımdır

Çözüm migration yapmamak değil; her tehlikeli migration’ı, her biri tek başına güvenli ve geri uyumlu olan küçük adımlara bölmektir. Bunun adı expand-contract (genişlet–daralt) kalıbıdır.

Bir kolonu yeniden adlandırmak istediğinizi düşünün. Tek adımda RENAME COLUMN, eski kolonu okuyan çalışan kodu anında kırar. Bunun yerine üç deploy:

Genişlet. Yeni kolonu ekle. Kod hem eskiye hem yeniye yazsın, hâlâ eskiden okusun.
Geçiş. Eski veriyi yeni kolona batch’ler hâlinde taşı. Kod artık yeniden okusun.
Daralt. Eski kolonu sil.

Her adım, hem bir önceki sürümdeki kod hem de yeni kod ile çalışır. Hiçbir an, çalışan kod ile şema uyumsuz değildir.

Güvenli reçeteler

Sık yapılan değişikliklerin kesintisiz hâlleri:

Yeni NOT NULL kolon. Tek adımda NOT NULL eklemek tabloyu tarar. Bölün:

-- 1. Önce nullable ekle
ALTER TABLE orders ADD COLUMN status text;

-- 2. Mevcut satırları batch'ler hâlinde doldur (uygulama tarafında)

-- 3. Kısıtı önce doğrulamadan ekle, sonra ayrı adımda doğrula
ALTER TABLE orders ADD CONSTRAINT orders_status_not_null
    CHECK (status IS NOT NULL) NOT VALID;
ALTER TABLE orders VALIDATE CONSTRAINT orders_status_not_null;

NOT VALID ile eklenen kısıt yeni satırlar için hemen geçerlidir ama mevcut satırları taramaz; VALIDATE ise tabloyu yalnızca SHARE UPDATE EXCLUSIVE lock ile tarar — yazmaları engellemez.

İndeks. Her zaman CONCURRENTLY:

CREATE INDEX CONCURRENTLY idx_orders_status ON orders (status);

Foreign key. Aynı iki adımlı kalıp: önce ADD CONSTRAINT ... NOT VALID, sonra VALIDATE CONSTRAINT.

lock_timeout. Bir migration, uzun süren bir sorgunun arkasında lock için beklerken kendisi de arkasındaki her şeyi bloklar. Bunu önlemek için migration oturumuna kısa bir lock_timeout verin — lock hemen alınamıyorsa migration beklemek yerine başarısız olsun, siz tekrar deneyin.

Kod ve şema birlikte uyumlu olmalı

Expand-contract’ın özü tek bir kuralda: her ara adımda, hem çalışmakta olan eski kod hem de yeni kod mevcut şema ile çalışabilmeli.

Veritabanı şeması, ileride lazım olur yazısında “tek yönlü kapı” dediğim şeydir — geri almak pahalıdır. Bu yüzden değişikliği büyük ve geri dönülmez tek bir adım olarak değil, her biri ayrı ayrı geri alınabilir küçük adımlar olarak tasarlayın.

Sıfır kesintili migration bir araç değil, bir disiplindir: her şema değişikliğini, çalışan kodun hiç fark etmeyeceği kadar küçük adımlara bölmek.

Tehlikeli olan değişikliğin kendisi değil, onu tek nefeste yapmaktır.

İndeksler: Eksik Yavaşlatır, Fazlası Yazmayı Öldürür

info@muhammetsafak.com.tr (Muhammet Şafak) — Sat, 05 Sep 2026 00:00:00 GMT

İki karşıt ekip gördüm. Biri tabloya hiç indeks koymamıştı — her sorgu bir sequential scan, her liste sayfası saniyeler sürüyordu. Diğeri tam tersini yapmıştı: “ne olur ne olmaz” diye her kolona bir indeks açmıştı ve şimdi her INSERT ağır aksak ilerliyordu.

İkisi de aynı yanılgının iki ucu: indeksi ücretsiz bir hız kaynağı sanmak.

İndeks ücretsiz hız değildir

Bir indeks okumayı hızlandırır, çünkü veritabanı tüm tabloyu taramak yerine sıralı bir yapıya bakar. Ama o sıralı yapı kendi kendine güncel kalmaz: tablodaki bir INSERT, o tablonun her indeksine bir girdi yazar; bir UPDATE de indeksli bir kolona dokunduğu anda aynısını yapar. İstisnalar var — indeksli hiçbir kolonu değiştirmeyen HOT güncellemesi indekslere dokunmaz, kısmi indeks yüklemi dışında kalan satırlar için güncellenmez, DELETE ise indeks girdilerini temizlemeyi VACUUM’a bırakır — ama bunlar istisna, varsayılan değil.

Yani her indeks bir takastır: okuma hızını, yazma maliyetiyle satın alırsınız. Beş indeksli bir tabloya tek satır eklemek, altı yapıyı birden güncellemektir. İndeks “bedava okuma hızı” değil, “yazmayla ödenmiş okuma hızı”dır.

Eksik indeks: tahmin değil, ölçüm

Eksik indeksi sorgu planından bulun, tahminden değil:

EXPLAIN ANALYZE
SELECT * FROM orders WHERE status = 'pending';

Çıktıda büyük bir tabloda Seq Scan görüyorsanız ve sorgu satırların küçük bir kısmını döndürüyorsa, muhtemelen bir indeks eksiktir. pg_stat_user_tables tablosunda seq_scan sayısı yüksek olan büyük tabloları tarayın — bunlar adaylarınızdır.

İndeksi gerçek, yavaş bir sorgu için ekleyin. “İleride lazım olabilir” diye eklenen indeks, spekülatif genelliğin veritabanı katmanındaki hâlidir.

Fazla indeks: kullanılmayanı bul

Ters yönde, hiç kullanılmayan indeksler her yazmayı boş yere pahalılaştırır. Onları da ölçümle bulun:

SELECT indexrelname, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0;

idx_scan = 0 olan bir indeks hiç okuma hızlandırmıyor ama her yazmaya maliyet ekliyor demektir. (Primary key ve unique kısıtların indekslerini elbette koruyun.) Bu, veri yoğunluklu sistemlerin yazma kırılma noktasında sayılan ilk temizliktir.

Doğru indeksi nasıl seçersiniz?

İndeks “var/yok”tan ibaret değildir; doğru türü ve şekli seçmek önemlidir:

Bileşik indekste kolon sırası. (a, b) indeksi, a’da eşitlik + b’de aralık sorgusuna hizmet eder; b’de tek başına yapılan bir arama da bu indeksi kullanabilir ama taranan indeks bölümünü daraltmaz — PostgreSQL 18 öncesinde indeksin tamamı taranır, 18’den itibaren skip scan optimizasyonu bunu daraltır. Eşitlikle filtrelenen kolonu başa, aralıkla filtreleneni sona koyun.
Kısmi indeks (partial). Sorgu hep aynı alt kümeye bakıyorsa indeksi de o alt kümeyle sınırlayın: CREATE INDEX ... WHERE status = 'active'. Daha küçük indeks, daha ucuz bakım.
Covering indeks. INCLUDE ile sık okunan kolonları indekse ekleyip veritabanının tabloya hiç gitmemesini sağlayabilirsiniz.
B-tree dışı türler. Eşitlik/sıralama için B-tree; jsonb ve tam metin için GIN; saf sıralı, append ağırlıklı veri için küçük ve ucuz BRIN.

Duplikat ve örtüşen indeksler

(a) üzerindeki bir indeks, zaten (a, b) indeksiniz varsa gereksizdir — bileşik indeks a ile başlayan sorgulara da hizmet eder. Bu tür örtüşmeleri periyodik olarak temizleyin; her biri sessiz bir yazma vergisidir.

Denge sorgu planıyla kurulur

Tek kural: indeksi ne tahminle ekleyin ne tahminle silin. Bir indeks, gerçek bir sorgu planı onu istediği için eklenir; bir indeks, istatistikler onu kimsenin kullanmadığını gösterdiği için silinir. Eksik ile fazla arasındaki denge, hislerle değil, EXPLAIN ANALYZE ve pg_stat_user_indexes ile kurulur.

İndeks yönetimi, “daha çok indeks daha iyi” sanısından kurtulmakla başlar. Her indeks bir okuma kazancı ve bir yazma maliyetidir; iyi yönetim, bu ikisini ölçerek dengede tutmaktır.

Eksik indeks sorguyu yavaşlatır; fazlası ise tüm tabloyu. İkisinden de ölçüm korur.