Vektör Veritabanı Seçimi: pgvector mı, Ayrı Servis mi?

Vektör veritabanı seçimi, kendi belgeleri üzerinde soru-cevap kuran ekiplerin ilk taktığı yer oluyor. Piyasada onlarca ürün var, hepsi kendi kıyaslamasında kazanıyor ve karar felç edici hâle geliyor. Oysa doğru soru "hangi ürün en iyi" değil: mevcut veritabanım yetmiyor mu?

Önce ölçek: gerçekten kaç vektörünüz var?

Somut bir örnek: 500 sayfalık bir kurumsal doküman seti, 500 kelimelik parçalara bölündüğünde kabaca 1.500-2.000 parça eder. Şirketin tüm iç dokümantasyonu bile çoğu zaman 50-100 bin parçayı geçmez. Bu ölçek, PostgreSQL üzerinde pgvector eklentisi için rahat bir aralıktır ve tek bir orta seviye sunucuda milisaniyeler mertebesinde cevap verir.

"Milyonlarca vektör" cümlesi genelde ürün tanıtımlarından ödünç alınıyor; kendi verinizi saydığınızda ortaya çıkan rakam çoğu zaman iki büyüklük sırası küçük oluyor. Karara başlamadan önce parçaları saymak, sonraki bütün tartışmayı kısaltıyor.

pgvector'ün asıl avantajı: tek yerde duran veri

Ayrı bir vektör servisi eklediğinizde tek bir bileşen değil, bir dizi yeni sorun ekliyorsunuz: iki sistem arasında tutarlılık, ayrı yedekleme, ayrı erişim yetkisi, ayrı izleme. Belge silindiğinde vektörün de silinmesi artık sizin sorumluluğunuz ve bu senkronizasyon, sessizce bozulmaya en açık yerlerden biri.

pgvector'de ise vektör, belgenin yanındaki bir sütundur. Belge silinince vektör de gider. Yetki kontrolü aynı sorguda yapılır. Yedekleme zaten vardır.

-- Filtre + vektör benzerliği tek sorguda
SELECT p.id, p.baslik, p.icerik
FROM belge_parca p
JOIN belge b ON b.id = p.belge_id
WHERE b.departman_id = 7          -- yetki/filtre
  AND b.silindi_mi = false
ORDER BY p.embedding <=> $1        -- kosinüs mesafesi
LIMIT 8;

Bu sorgunun ayrı bir vektör servisiyle karşılığı iki adımdır: önce servisten aday çekip sonra veritabanından filtrelemek. Filtre çok seçiciyse (örneğin kullanıcı yalnızca kendi departmanının 200 belgesini görebiliyorsa) bu iki adımlı yaklaşım hem yavaş hem de sonuç kalitesi düşük olur; çünkü servis, filtreyi bilmeden ilk N adayı seçer ve o adayların çoğu elenir.

İndeks: asıl performans kararı

pgvector'de indekssiz arama, tüm satırları tarar. Birkaç bin satırda bu fark edilmez; yüz binde belirgin şekilde yavaşlar. İki indeks tipi var ve seçim, veri güncelleme sıklığınıza bağlı:

• HNSW — sorguda hızlı ve isabetli, ama indeks oluşturması yavaş ve bellek ister. Veri nadiren değişiyorsa doğru tercih.
• IVFFlat — kurulumu hızlı, belleği az; ancak veri dağılımı değiştikçe isabet oranı düşer, periyodik yeniden inşa gerektirir.

Kritik ayrıntı: her iki indeks de yaklaşık arama yapar. Yani "en yakın 8 sonuç" garantisi vermez, "büyük olasılıkla en yakın 8" verir. Bu, arama sonucunun bir insana gösterildiği senaryolarda sorun değildir; ancak sonuç doğrudan otomatik bir karara giriyorsa kabul edilebilir isabet oranını ölçerek belirlemek gerekir.

Ne zaman ayrı servise geçilir?

Somut eşikler:

Bu belirtilerin hiçbiri yoksa, ayrı servis çoğunlukla erken optimizasyondur; getirdiği işletme yükü, sağladığı hızın önüne geçer.

Hangi seçeneği seçerseniz seçin: bunları saklayın

Her vektör kaydında en az şu üç bilgi bulunsun: embedding modelinin adı ve sürümü, parçalama stratejisi (kaç karakter, kaç örtüşme) ve kaynak belgenin sürümü. Model değiştiğinde hangi kayıtların yeniden üretileceğini yalnızca bu üçlü söyler. Bu alanları eklemeyen ekipler, ilk model değişiminde tüm koleksiyonu silip baştan üretmek zorunda kalıyor.

Sonuç

Vektör veritabanı seçimi çoğu projede aslında bir seçim değil: mevcut PostgreSQL'inize bir eklenti kurup devam etmek yeterli. Ayrı servisi, ölçüm sonucu bir darboğaz gösterdiğinde değerlendirin; ürün karşılaştırma tablolarına bakarak değil. Mimarinin geri kalanı için RAG mimarisi yazısı, veri kalitesi tarafı için veri temizleme yazısı iyi birer başlangıç. Yasal sınırları hatırlamak için de KVKK ve pratik sınırlar yazısına bakmakta fayda var.

Eklentinin resmî belgeleri: pgvector deposu.