PGVector’a Karşı Argümanlar

 (alex-jacobs.com)
9 puan yazan GN⁺ 2025-11-04 | 5 yorum | WhatsApp'ta paylaş
  • Postgres eklentisi pgvector, vektör benzerliği aramasını destekler; ancak demo seviyesi ile gerçek üretim ortamı arasında büyük bir fark vardır
  • IVFFlat ve HNSW indekslerinin her ikisinin de belirgin artıları ve eksileri vardır; özellikle HNSW’de indeks oluştururken birkaç GB düzeyinde bellek kullanımı ve uzun derleme süreleri sorun yaratır
  • Gerçek zamanlı arama ve indeks güncellemesi yapısal olarak zordur; sürekli ekleme ve güncelleme durumunda lock çekişmesi ve performans düşüşü ortaya çıkar
  • Filtreleme stratejileri (Pre/Post) ve sorgu planlayıcısının sınırları nedeniyle arama doğruluğu ile hız arasında dengesiz bir denge oluşur
  • Özel vektör veritabanlarının (Pinecone, Weaviate vb.) sunduğu özelliklerin elle uygulanması gerekir; bu da sonuçta operasyonel karmaşıklık ve maliyet artışına yol açar

pgvector’ün sınırlamalarına genel bakış

  • pgvector, Postgres’e vektör benzerliği arama özelliği ekleyen bir eklentidir; basit demolarda iyi çalışsa da üretim ortamında ölçeklenebilirlik sorunları ortaya çıkar
  • Pek çok blog yazısı yalnızca kurulum ve basit sorgu örneklerini ele alır; üretimde karşılaşılan performans, bellek ve indeks yönetimi sorunlarından ise neredeyse hiç bahsetmez

İndeks seçimi sorunu

  • pgvector, IVFFlat ve HNSW olmak üzere iki tür indeks sunar
    • IVFFlat: Küme tabanlı bir yapıdır; indeks oluşturma hızı yüksektir ancak küme sayısı ayarının performans ve doğruluk üzerinde büyük etkisi vardır
      • Kümeler yeniden dağıtılamadığı için düzenli indeks yeniden oluşturma gerekir
    • HNSW: Çok katmanlı bir grafik yapısıdır; doğruluk ve tutarlı performans sunar, ancak indeks oluştururken bellek kullanımı çok yüksektir ve yavaştır
  • Milyonlarca vektör için indeks oluşturulurken 10 GB’tan fazla RAM kullanımı mümkün olabilir; bu da üretim veritabanının kararlılığı için doğrudan bir tehdittir
Reklam

Gerçek zamanlı aramanın zorlukları

  • Yeni veri eklendikten sonra hemen aranabilir olması gerekir; ancak indeks güncelleme yapısı nedeniyle gerçek zamanlı yansıtma zordur
    • IVFFlat: Yeni vektörler mevcut kümelere eklenir; zamanla küme dengesizliği oluşur → periyodik rebuild gerekir
    • HNSW: Ekleme sırasında grafiğin güncellenmesi nedeniyle lock çekişmesi ve bellek yükü oluşur
  • İndeks yeniden oluşturulurken veri tutarlılığını korumak ve hizmet sürekliliğini sağlamak zordur
  • Üretim ortamında staging table, çift indeks, offline build, eventual consistency gibi çeşitli dolaylı stratejilere ihtiyaç duyulur

Filtreleme ve sorgu planlayıcısının sınırları

  • status, user_id, category gibi metadata filtreleme ile vektör aramayı birleştirirken Pre-filter ile Post-filter seçimi performansı ciddi biçimde etkiler
    • Pre-filter, seçici filtrelerde avantajlıdır; ancak veri büyükse yavaştır
    • Post-filter hızlıdır, ancak filtre sonrasında sonuçların kaçırılması mümkündür
  • Postgres sorgu planlayıcısı, vektör benzerliği için maliyet modelini anlayamaz; istatistik bilgileri de hatalı olduğundan verimsiz yürütme planları üretir
  • Sonuç olarak CTE, partitioning, sorgu yeniden yazımı gibi geçici çözümler gerekir; bu da ölçek büyüdükçe verimsizleşir
Reklam

Özel vektör veritabanlarıyla karşılaştırma

  • Pinecone, Weaviate, OpenSearch k-NN gibi sistemler filtreleme stratejisinin otomatik seçimi, hibrit arama, gerçek zamanlı indeksleme ve yatay ölçekleme özelliklerini varsayılan olarak sunar
  • pgvector’de bu özellikleri doğrudan kendiniz uygulamanız gerekir; bu da operasyonel karmaşıklık ve bakım yükü doğurur
  • Timescale’in pgvectorscale çözümü StreamingDiskANN, artımlı indeks oluşturma ve filtreleme iyileştirmeleri sunar; ancak
    • AWS RDS’de desteklenmez ve ek eklenti kurulumu ile yönetim yükü getirir

Maliyet ve operasyon değerlendirmeleri

  • Özel vektör veritabanları ücretli servislerdir; ancak Postgres altyapısında aşırı provizyonlama, indeks yönetimi ve mühendislik süresi hesaba katıldığında pratikte daha ucuz olabilirler
  • Örnek olarak Turbopuffer aylık $64’tan başlar ve operasyonel sadelik ile ölçeklenebilirlik sunar

Sonuç ve öneriler

  • pgvector teknik olarak çok iyi olsa da üretim ortamında birçok kısıta sahiptir
  • Üretim sistemi kurarken dikkate alınması gereken temel noktalar
    1. İndeks yönetiminin karmaşıklığı ve yüksek bellek gereksinimi
    2. Sorgu planlayıcısının sınırları nedeniyle filtrelemede verimsizlik
    3. Gerçek zamanlı indekslemenin maliyeti ve kalite düşüşü
    4. Blog içeriklerinin aşırı basitleştirilmesi
    5. Özel vektör veritabanlarının neden var olduğu ve sundukları verimlilik
  • Sonuç olarak, Postgres entegrasyonunun sadeliğinden daha büyük olan şey operasyonel karmaşıklıktır; çoğu ekip için özel bir vektör veritabanı kullanmak daha gerçekçi bir seçimdir

İlgili okumalar

5 yorum

 
kaydash 2025-11-05

Yine de karma sorgular (embedding + geleneksel SQL) için pg_vector gibisi yok.
 
yangeok 2025-11-04

Ekosistemin sağlıklı olması için, her derde deva anlatılarına yönelik karşı argümanların da çok olması gerektiğini düşünüyorum.
 
ethanhur 2025-11-05

Katılıyorum. Halihazırda PostgreSQL'i iyi kullanan bir organizasyonun küçük veriyle VectorDB'ye başladığı durumda pgVector'ın mükemmel bir seçenek olduğu açık; ancak trafik, özellikle de yazma trafiği arttığında, asıl yazının yazarının söylediği sorunun darboğaz haline geldiği anlaşılıyor.
 
ndrgrd 2025-11-04

Doğru. Çünkü hiçbir şey kusursuz değil. "Daha acil başka işler var" demek bir dereceye kadar kabul edilebilir, ama "mevcut seviye de yeterli" anlayışına göz yumulmaması gerektiğini düşünüyorum.
 
GN⁺ 2025-11-04
Hacker News görüşleri

  • Biz Discourse'ta zaten binlerce veritabanında pgvector'ı production ortamında kullanıyoruz.
    Sayfa görüntülemelerinin çoğunda kullanılıyor ve Iterative Scans özelliği sürüm 0.8.0 ile eklenerek pre/post filtering sorunlarını iyileştirdi.
    Tek bir servis için özel bir vektör veritabanı daha kolay olabilir, ama bu her derde deva bir çözüm değil.

    • Biz quantization'ı aktif olarak kullanıyoruz.
      Depolama için halfvec (16bit float), indeks için bit (binary vectors) kullanarak hem depolama maliyetini hem de performansı optimize ettik.
    • Bizim şirket Halcyon'da trilyonlarca embedding ile çalışıyoruz ve Postgres bu ölçek için uygun değildi.
      Vespa kullanarak düğüm düzeyinde map-reduce tarzı arama yapıyoruz.
      Postgres'te benzer bir şeyi yapmak için sharding ve karmaşık uygulama mantığı gerekecek gibi görünüyor.
      Reindexing veya metadata denormalization'ın da ister istemez uzun süreceğini düşünüyorum.
      Yine de vektör veritabanları sihirli çözüm değil; Vespa gibi ilişkisel filtreleme destekleyen sistemler çok daha verimli.
    • pgvector'ı production'da kullanan çok kişi var.
      Ancak iterative scan temel bir çözümden ziyade geçici bir önlem gibi.
      ef_search, max_search_tuples gibi parametreleri anlamak gerekiyor ve planner filtrelenmiş vektör aramasının maliyet modelini tam olarak kavrayamıyor.
      Sonuçta mesele, akıllı bir query planner'ı kendiniz ayarlayacak kapasiteniz olup olmadığı ya da bunu uzmanlaşmış bir servise bırakıp bırakmayacağınız.
    • Filtrelemeyi indeks taraması sırasında yapan bir yaklaşım da var.
      Microsoft'un makalesinde açıklanan yöntemi Timescale'in pgvectorscale aracı uyguluyor.
      Bu yöntem basit pre/post filtering'e göre daha verimli olabilir.
    • Bunun hangi amaçla kullanıldığını merak ediyorum. Acaba keyword + vector birleşimli bir hibrit arama sistemi mi?

  • Biz VectorChord ile, blogda bahsedilen pgvector sorunlarının çoğunu çözdük.
    IVF + quantization kullanarak pgvector'ın HNSW'sine göre 15 kat daha hızlı update desteği sağlıyoruz.
    16vCPU, 32GB bellek ile 100 milyon adet 768 boyutlu vektörü 20 dakikada indeksleyebiliyoruz.
    CREATE INDEX CONCURRENTLY ile veri kaybı olmadan reindexing yapılabiliyor.
    pre/post filtering ve BM25 tabanlı hibrit arama da destekleniyor.
    Ayrıntılar için VectorChord bloguna bakabilirsiniz.

    • quantization ve IVF kullanıldığında gerçek recall değerinin ne olduğunu merak ediyorum.
    • Postgres + VectorChord + sharding ile 3 milyar vektör işleten müşterilerimiz var.
      İlgili örnek olay bu blogda görülebilir.
    • VectorChord'u değerlendirdik ama RDS tarafından desteklenmediği için ayrı bir servis eklememiz gerekiyordu; bu yüzden devreye alamadık.

  • İndeks oluşturma çok bellek kullanır ama maintenance_work_mem ile kontrol edilebilir.
    İndeks yeniden oluşturma REINDEX CONCURRENTLY ile yapılabilir ve HNSW update'leri B+tree update'lerine benzer bir kavramdır.
    Bu yazı, sanki Postgres belgeleri düzgün okunmamış gibi bir izlenim veriyor.

    • Ancak maintenance_work_mem sınırlandırılırsa indeksleme yavaşlar.
      B+tree yalnızca log H sayfayı etkilerken, HNSW binlerce vektörü değiştirmek zorunda kalır.
    • HNSW indeksleri yüzlerce GB ile birkaç TB arasında olabilir.
      Bunu yeniden oluşturmak için veritabanı kapasitesini iki kattan fazla artırmak gerekir ve bu diğer iş yüklerini de etkiler.
      REINDEX CONCURRENTLY de uzun sürer.
      HNSW ekleme işlemlerinin karmaşıklığı düşük olsa bile sabit maliyeti yüksek olduğu için pratikte ciddi yük oluşturur.
    • maintenance_work_mem gibi ayarlar olsa bile, production'da GB seviyesinde RAM'i saatler boyunca işgal etmek risklidir.
      REINDEX CONCURRENTLY de diski 2-3 kat daha fazla kullanır ve performansı etkiler.
      Sonuçta mesele Postgres'in eksik olması değil, operasyonel karmaşıklığın büyük olmasıdır.
      Özel vektör veritabanları bunları otomatik ele aldığı için, küçük ekipler için çok daha verimlidir.

  • Turbopuffer'ın aylık başlangıç fiyatının 64 dolar olması, pgvector'ın neden popüler olduğunu açıklıyor.
    64 dolar pahalı geliyorsa pgvector kullanırsınız; ucuz geliyorsa zaten kullanım senaryonuz yeterince karmaşıktır ve özel bir vektör veritabanı daha uygun olur.

  • GCP müşterileri arasında da pgvector HNSW'yi production'da kullanan çok örnek gördüm.
    Ancak bu en fazla 0 ila 10 milyon vektör ölçeğinde gerçekçi.
    ETL, operasyonel ek yük ve tutarlılık sorunları hesaba katılmalı.
    Transaction, hibrit arama ve düşük gecikme gerekiyorsa AlloyDB + ScaNN daha iyi bir seçimdir.
    (Bu arada, ben GCP'de ScaNN'i geliştirdim ve şu anda AlloyDB Semantic Search ekibine liderlik ediyorum.)

    • AlloyDB açık kaynak olmadığı için başka bir pazarı hedefleyen bir ürün.

  • Benim temel ilkem YAGNI.
    Mümkün olduğunca servis sayısını düşük tutar, sorun çıktığında yeni bir şey eklerim.
    Postgres yetiyorsa onunla devam ederim; yetmiyorsa da o zaman tam olarak neye ihtiyaç olduğunu öğrenmiş olurum.

    • Ama bu yaklaşım çoğu zaman ters tepebilir.
      Gerçek zamanlı vektör yazma, SQL filtreleri ile benzerlik aramasını birleştirme gibi şeyler önemsiz görünebilir ama pratikte zorunlu özelliklerdir.
      Ölçek büyüdüğünde bu kısıtlar ölümcül hâle gelir.
    • Veritabanı bir kez seçildiğinde değiştirmesi zor olduğu için, en baştan dikkatli olunmalı.

  • Vektör embedding modelleri, büyük veri kümeleri olmasa bile çok faydalı olabilir.
    Örneğin belge arama veya ürün bilgisi arama gibi kullanım senaryolarında.
    Ben, dosya sistemi gibi belge yazıldığında indeksin otomatik güncellendiği bir arayüz istiyorum.
    Bu yüzden Amazon S3 Vectors(bağlantı) gibi servisler ilgimi çekiyor.
    Gerçek kullanım deneyimini merak ediyorum.

  • Bahsedilen sorunlar zaten çözüldü ve ben PGVector kullanmayı tercih ediyorum.
    Eğer Postgres Kafka'nın yerini alıp saniyede 100 bin olayı işleyebiliyorsa, Chroma gibi özel bir vektör veritabanı yerine PGVector da gayet yeterli olabilir.
    İlgili bağlantı

    • Özellikle hangi sorunların çözüldüğünü merak ediyorum.

  • pgvector kullanım senaryolarının çoğu, “teknik dokümantasyon tabanlı chatbot” gibi küçük veri kümeleridir.
    Veri sık değişmez ve multi-tenancy olmadığı için filtreleme sorunu da azdır.
    Buna karşılık Chroma, SPANN, SPFresh, hibrit arama desteği sunuyor ve tamamen Apache 2.0 açık kaynak.
    Kullanım bazlı fiyatlandırma ile aylık 1 dolar seviyesinde maliyetle de kullanılabiliyor.

  • Son 1 yıldır geliştirdiğim Redis Vector Sets bu sorunları çözüyor.
    HNSW'yi doğrudan implemente ederek gerçek zamanlı update imkânı sağlıyor ve silme durumunda bellek de anında geri kazanılıyor.
    Saniyede yüz binlerce ops/sec ekleme, 50 bin ops/sec arama hızını destekliyor.
    Varsayılan olarak quantization desteklediği için bellek verimliliği de yüksek.
    Ayrıntıları README belgesinde toparladım.
    Şu anda replication özelliği de tamamen test edilmiş durumda.