Pinecone, Açık Kaynaklı Postgres Arama Eklentisi Pg_pinecone’ı Piyasaya Sürüyor

Pinecone, 27 Ekim 2026’da şirketin büyük ölçekte çalıştırdığını belirttiği vektör arama motorunu, uygulamaların hâlihazırda sakladığı pgvector sütunlarına taşıyan, Apache 2.0 lisanslı açık kaynaklı bir Postgres eklentisi olan pg_pinecone’ı yayımladı. Şirketin bildirdiği kıyaslama testlerinde, 1 milyon adet 768 boyutlu vektör için eklentinin yerel indeksinin boyutu 136 MB olarak ölçüldü; HNSW’nin halfvec üzerindeki boyutu 2,0 GB, tam boyutlu vektörler üzerindeki boyutu ise 4,1 GB oldu.

Sürüm, Harshita Daddala ve Anthony Mahanna’nın kaleme aldığı bir duyuru yazısında tanıtıldı. Yazıya göre Postgres’te vektör araması yapmanın yaygın yolu, performansı korumak için giderek daha fazla bellek gerektiren, oluşturulması uzun süren ve filtreli aramalarda doğruluğu düşen HNSW gibi bir grafik indeksi kullanmak. Bir sorgu tek bir kullanıcıya veya kiracıya göre sınırlandığında, grafik indeksi sorgudaki LIMIT değerinden daha az satır döndürebiliyor. pg_pinecone ise filtreyi arama sırasında uyguluyor. Pinecone, bunun dar kapsamlı aramalarda bile sonuç kümesinin tamamının döndürülmesini sağladığını ve varsayılan motorunda verilerin Postgres dışına hiç çıkmadığını belirtti.

Tek Bir İndeksin Arkasındaki Üç Motor

pg_pinecone, pgvector’da zaten bulunan vektör sütunlarıyla çalışır. Uygulama Postgres’e aynı şekilde bağlanır ve ORDER BY embedding <=> $1 LIMIT 10 gibi aynı SQL sorgularını gönderir. Tablolar, tam vektörler de dâhil olmak üzere, bulundukları yerde kalır ve sistem kaydı Postgres olmaya devam eder.

Her tablo üç motordan birini kullanır. Varsayılan olan yerel motor, indeksini tamamen Postgres içinde oluşturur ve arar; Pinecone hesabı, API anahtarı veya ağ bağlantısı gerektirmez. pgvector motoru, mevcut bir pgvector indeksi olan HNSW veya IVFFlat üzerinde arama yapar. Projenin GitHub deposunda, bu motorun hâlihazırda pgvector indeksi bulunan ve filtreleme yapmayan tablolar için uygun olduğu belirtiliyor. Uzak motor, aramayı Pinecone’un yönetilen hizmetindeki sunucusuz bir indekse yönlendirir; bu motor, tek bir Postgres sunucusunun kapasitesini aşan tablolar için tasarlanmıştır. Bir tabloyu motorlar arasında geçirmek için pinecone.set_engine() çağrısını bir kez yapmak yeterlidir; sorgular değişmez ve her geçiş geri alınabilir.

Yerel Motor Nasıl Arama Yapar?

pgvector’ın HNSW’si gibi yerel motor da yaklaşık en yakın komşu algoritması kullanır; ancak grafiğin yerine benzer vektörleri kümeler hâlinde gruplandıran bir ters dosya indeksi koyar. Her vektör, boyut başına yaklaşık bir bit ve birkaç düzeltme değeri içeren kuantize edilmiş bir RaBitQ kodu olarak saklanır. Duyuru yazısında bu yöntem Gao ve Long’un SIGMOD 2024 çalışmasına atfediliyor. Her kümenin kodları bir arada paketlenir; böylece arama, grafik üzerinde farklı noktalara atlamak yerine art arda gelen birkaç sayfayı okur.

Arama üç adımda gerçekleşir: Önce sorgu vektörü her kümenin ağırlık merkeziyle karşılaştırılarak en yakın kümeler belirlenir; ardından her satır için RaBitQ kodundan tahmini bir mesafe hesaplanır ve en iyi adaylar seçilir; son olarak bu adaylar, tablodaki tam vektörleri kullanılarak yeniden sıralanır.

Filtreleme, arama işleminin içinde gerçekleşir. Pinecone, pgvector’ın HNSW’sinin sonradan filtreleme yaptığını; önce en yakın komşuları bulup ardından WHERE koşulunu uyguladığını belirtti. Bu nedenle dar kapsamlı bir filtre, adayların çoğunu eler ve yinelemeli taramalar listeyi yeniden doldururken süreyi artırır; relaxed_order kullanıldığında doğruluk da düşer. Yerel motor, her satırın kodunun yanında filtre sütunundaki değeri saklar ve indeks oluşturulurken her değere karşılık gelen satırları sayar. Varsayılan olarak satırların %3’ünü veya daha azını kapsayan dar filtrelerde, ön filtreleme yapar; tüm kümelerde eşleşen her satırı tarar ve sonuçların kesin olması için her birini tam vektörünü kullanarak puanlar. Daha geniş filtrelerde ise tek aşamalı filtreleme uygular: En yakın kümelerin yarısına kadarını arar ve puanlama yapmadan önce her kümenin içindeki filtreyi kontrol eder.

Yeni eklenen satırlar en yakın kümeye katılır ve hemen aranabilir hâle gelir. Küme ağırlık merkezleri, indeks oluşturulurken yerleştirildikleri konumlarda kaldığından duyuru yazısı, kümeleri yeniden dengelemek için REINDEX komutunun çalıştırılmasını veya büyük değişikliklerden sonra otomatik bakımı etkinleştirmeyi öneriyor. Örneğin toplu yükleme tablonun boyutunu ikiye katlayabilir.

Pinecone’un Bildirdiği Kıyaslama Sonuçları

Pinecone, tam boyutlu vektörler ve halfvec kullanarak 1 milyon adet 768 boyutlu wiki_dpr vektörü üzerinde yerel motoru pgvector’ın HNSW indeksiyle karşılaştırdı. Testler, 16 vCPU ve 128 GB RAM’e sahip bir AWS r6id.4xlarge bulut sunucusunda yürütüldü. Filtresiz gecikme, oluşturma süresi ve indeks boyutu PostgreSQL 17 üzerinde tek bir oturumda; filtreli arama PostgreSQL 18 üzerinde başka bir oturumda; bellek sınırı uygulanmış yapılandırma ise üçüncü bir oturumda ölçüldü. Gecikme, tek istemciyle k=10 için medyan p50 olarak raporlandı. Şirket, testleri yeniden çalıştırmak için gereken tüm kurulumun ve komutların depodaki bir kıyaslama aracı README dosyasında yer aldığını belirtti.

Pinecone, 1 milyon vektör için yerel indeks boyutunun 136 MB olduğunu; HNSW’nin halfvec üzerindeki boyutunun 2,0 GB, tam boyutlu vektörler üzerindeki boyutunun ise 4,1 GB olduğunu bildirdi. Filtresiz aramalarda şirket, 0,95 recall değerinde 1,3 ms gecikme raporladı; HNSW’de bu değer halfvec için 1,7 ms, tam boyutlu vektörler için 2,7 ms oldu. 0,99 recall değerinde ise yerel motorun gecikmesi 2,3 ms, HNSW’ninki sırasıyla 4,7 ms ve 6,7 ms olarak bildirildi. Satırların %10’uyla eşleşen bir filtre kullanıldığında Pinecone, yerel motorun tek aşamalı filtrelemeyle 12,3 ms’de 1,000 recall değerine ulaştığını; yinelemeli taramalar kullanan HNSW’nin ise 5,9 ms’de en fazla 0,920 recall değerine ulaştığını bildirdi. %1 filtre kullanıldığında ise 8,3 ms’de 0,981 recall elde edildiğini açıkladı. Bildirilen indeks oluşturma süreleri, yerel motor için 45 saniye; HNSW için halfvec üzerinde 62 saniye, tam boyutlu vektörlerde ise 79 saniyeydi.

Kullanılabilirlik ve İsteğe Bağlı Pinecone Özellikleri

pg_pinecone için PostgreSQL 17 veya 18, süper kullanıcı erişimi ve sunucuda yüklü pgvector gerekir. GitHub’daki önceden derlenmiş sürümlerden veya Docker Hub’daki pineconeteam/pg_pinecone imajı olarak yüklenebilir. README’de bu imaj, pg_pinecone eklenmiş pgvector/pgvector imajı olarak tanımlanıyor ve 0.11.0-pg17 gibi her bir Postgres ana sürümü için ayrı bir etiketle yayımlanıyor; uzak motoru çalıştırmak için uzantının shared_preload_libraries üzerinden yüklenmesi de gerekiyor. Kurulum, vector ve pg_pinecone uzantılarını oluşturuyor ve pinecone.create_index() çağrısıyla bir dizin oluşturuyor. Proje ayrıca Rust araç zinciri ve cargo-pgrx 0.19.2 kullanılarak kaynak koddan derlenebiliyor.

İsteğe bağlı bir Pinecone API anahtarıyla uzak motor, aramalar kopyalama tamamlanana kadar Postgres’te çalışmaya devam ederken gömme vektörlerini arka planda bir Pinecone diziniyle eşitler. Yazıda ayrıca isteğe bağlı üç özellik daha anlatılıyor: embed() çağrıları, metni SQL üzerinden gömme vektörlerine dönüştürmek için Pinecone’un çıkarım hizmetini kullanıyor, hem yerel hem de uzak motorlarla çalışıyor ve ilk derleme için Pinecone’un ücretsiz katmanı kapsamında sunuluyor; BM25 tam metin araması, aynı tabloda vektör aramasıyla birlikte çalışıyor ve BM25, vektör veya hibrit sorgular SQL üzerinden yürütülebiliyor; rerank() ise en üst sıradaki sonuçları Pinecone’un yeniden sıralama modelleriyle yeniden sıralıyor.

docs.pinecone.io adresindeki belgeler kurulum, depolama motorları, motor değiştirme ve tam metin aramasını kapsarken, depo SQL başvuru kılavuzu, operatörler için çalışma kılavuzu ve olağanüstü durum kurtarma kılavuzu da sunuyor. Pinecone, bunun projenin ilk sürümü olduğunu belirtti; pg_pinecone’un bakımını yaptığını ve her çekme isteğini incelediğini söyledi. Ayrıca herkese açık yol haritasını GitHub sorun bildirimleri, Discord topluluğu ve aylık açık görüşme saatleri aracılığıyla paylaşılan geri bildirimler doğrultusunda oluşturacağını ifade etti.