Pinecone lansează pg_pinecone, o extensie open-source de căutare pentru Postgres

Pinecone a lansat pe 27 octombrie 2026 pg_pinecone, o extensie open-source pentru Postgres, licențiată sub Apache 2.0, care aduce în coloanele pgvector pe care aplicațiile le stochează deja motorul de căutare vectorială despre care compania spune că îl folosește la scară largă. În benchmarkurile raportate de companie, indexul nativ al extensiei pentru 1 milion de vectori cu 768 de dimensiuni a avut 136 MB, comparativ cu 2.0 GB pentru HNSW pe halfvec și 4.1 GB pentru vectorii de dimensiune completă.

Lansarea a fost prezentată într-o postare de anunț semnată de Harshita Daddala și Anthony Mahanna. Potrivit postării, metoda obișnuită de a efectua căutări vectoriale în Postgres este folosirea unui index de tip graf, precum HNSW, care necesită tot mai multă memorie pentru a-și menține performanța, se construiește lent și reduce precizia căutărilor cu filtrare; când o interogare este limitată la un singur utilizator sau client, un index de tip graf poate returna mai puține rânduri decât valoarea LIMIT din interogare. În schimb, pg_pinecone aplică filtrul în timpul căutării, ceea ce, potrivit Pinecone, permite returnarea unui set complet de rezultate chiar și pentru un domeniu restrâns, iar datele nu părăsesc niciodată Postgres în cazul motorului implicit.

Trei motoare pentru un singur index

pg_pinecone funcționează cu coloanele vectoriale stocate deja în pgvector. O aplicație se conectează la Postgres în același mod și trimite aceleași interogări SQL, de exemplu ORDER BY embedding <=> $1 LIMIT 10, în timp ce tabelele, inclusiv vectorii compleți, rămân la locul lor, iar Postgres continuă să fie sursa de referință a datelor.

Fiecare tabel folosește unul dintre cele trei motoare. Motorul nativ, implicit, își construiește și caută indexul în întregime în Postgres, fără cont Pinecone, cheie API sau apeluri de rețea. Motorul pgvector caută într-un index pgvector existent, HNSW sau IVFFlat, iar depozitul GitHub al proiectului îl descrie ca fiind potrivit pentru tabele care au deja un index pgvector și nu folosesc filtre. Motorul la distanță direcționează căutările către un index serverless din serviciul gestionat Pinecone și este destinat tabelelor care au depășit capacitatea unui singur server Postgres. Schimbarea motorului unui tabel se face printr-un singur apel la pinecone.set_engine(), interogările rămân neschimbate, iar fiecare schimbare poate fi anulată.

Cum caută motorul nativ

La fel ca HNSW din pgvector, motorul nativ folosește un algoritm aproximativ pentru găsirea celor mai apropiați vecini, dar înlocuiește graful cu un index de tip fișier inversat, care grupează vectorii similari în clustere. Fiecare vector este stocat sub forma unui cod RaBitQ cuantizat, de aproximativ un bit pe dimensiune, la care se adaugă câteva valori de corecție; metoda este atribuită în postare lui Gao și Long, în cadrul SIGMOD 2024. Codurile fiecărui cluster sunt grupate împreună, astfel încât o căutare citește câteva pagini contigue, în loc să sară dintr-un loc în altul într-un graf.

O căutare se desfășoară în trei etape: se identifică cele mai apropiate clustere comparând vectorul interogării cu centrul fiecărui cluster, se calculează o distanță estimată pentru fiecare rând pe baza codului său RaBitQ și se păstrează cei mai buni candidați, apoi aceștia sunt reordonați folosind vectorii lor compleți din tabel.

Filtrarea are loc în timpul căutării. Potrivit Pinecone, HNSW din pgvector aplică filtrele după căutare: mai întâi găsește cei mai apropiați vecini, apoi aplică clauza WHERE, astfel încât un filtru restrictiv elimină majoritatea candidaților, iar scanările iterative completează din nou lista, cu prețul unui timp mai mare și, când se folosește relaxed_order, al unei precizii mai mici. Motorul nativ stochează valoarea coloanei de filtrare lângă codul fiecărui rând și numără rândurile pentru fiecare valoare în timpul construirii indexului. Pentru filtre restrictive, implicit cele care vizează cel mult 3% dintre rânduri, aplică filtrul înainte de căutare: parcurge toate rândurile care corespund filtrului din toate clusterele și calculează scorul fiecăruia folosind vectorul complet, astfel încât rezultatele sunt exacte. Pentru filtre mai largi, folosește filtrarea într-o singură etapă: caută în cel mult jumătate dintre cele mai apropiate clustere și verifică filtrul în fiecare cluster înainte de calcularea scorurilor.

Înregistrările noi sunt adăugate în cel mai apropiat cluster și pot fi căutate imediat. Deoarece centroizii rămân în pozițiile stabilite la construirea indexului, postarea recomandă să se ruleze REINDEX sau să se activeze întreținerea automată după modificări ample, cum ar fi o încărcare în masă care dublează tabelul, pentru a reechilibra clusterele.

Benchmarkuri raportate de Pinecone

Pinecone a comparat motorul nativ cu indexul HNSW din pgvector, folosind vectori de dimensiune completă și halfvec, pe 1 milion de vectori wiki_dpr cu 768 de dimensiuni. Testele au fost efectuate pe o instanță AWS r6id.4xlarge cu 16 vCPU și 128 GB de RAM: latența fără filtrare, timpul de construire și dimensiunea indexului au fost măsurate într-o sesiune pe PostgreSQL 17, căutarea cu filtrare — într-o altă sesiune pe PostgreSQL 18, iar configurația cu memorie limitată — într-o a treia sesiune. Latența este raportată ca mediană p50 la k=10, cu un singur client, iar compania a precizat că întreaga configurație și comenzile pentru repetarea testelor se găsesc într-un fișier README al unei suite de benchmarkuri din depozit.

Pentru cei 1 milion de vectori, Pinecone a raportat un index nativ de 136 MB, comparativ cu 2.0 GB pentru HNSW pe halfvec și 4.1 GB pentru vectorii de dimensiune completă. În căutările fără filtrare, compania a raportat o latență de 1.3 ms la un recall de 0.95, comparativ cu 1.7 ms pentru HNSW pe halfvec și 2.7 ms pentru vectorii de dimensiune completă, precum și 2.3 ms la un recall de 0.99, comparativ cu 4.7 ms și, respectiv, 6.7 ms. Pentru un filtru care corespundea la 10% dintre rânduri, Pinecone a raportat că motorul nativ a atins un recall de 1.000 în 12.3 ms folosind filtrarea într-o singură etapă, în timp ce HNSW cu scanări iterative a atins un recall de cel mult 0.920 în 5.9 ms; pentru un filtru de 1%, a raportat un recall de 0.981 în 8.3 ms. Timpii de construire a indexului raportați au fost de 45 de secunde pentru motorul nativ, față de 62 de secunde pentru HNSW pe halfvec și 79 de secunde pentru vectorii de dimensiune completă.

Disponibilitate și funcționalități opționale ale Pinecone

pg_pinecone necesită PostgreSQL 17 sau 18, acces de superutilizator și instalarea pgvector pe server. Se instalează din versiunile precompilate disponibile pe GitHub sau folosind imaginea pineconeteam/pg_pinecone de pe Docker Hub, pe care README o descrie drept imaginea pgvector/pgvector la care s-a adăugat pg_pinecone, publicată cu câte o etichetă pentru fiecare versiune majoră de Postgres, de exemplu 0.11.0-pg17; pentru a rula și motorul la distanță, extensia trebuie încărcată și prin shared_preload_libraries. Configurarea creează extensiile vector și pg_pinecone și construiește un index prin apelul pinecone.create_index(), iar proiectul poate fi compilat din codul sursă cu un lanț de instrumente Rust și cargo-pgrx 0.19.2.

Cu o cheie API Pinecone opțională, motorul la distanță sincronizează în fundal încorporările cu un index Pinecone, în timp ce căutările continuă să ruleze în Postgres până la finalizarea copierii. Articolul descrie încă trei funcții opționale: apelurile embed() folosesc serviciul de inferență Pinecone pentru a transforma textul în încorporări direct din SQL, funcționează atât cu motorul nativ, cât și cu cel la distanță, iar pentru o primă compilare sunt acoperite de nivelul gratuit Pinecone; căutarea full-text BM25 rulează alături de căutarea vectorială în același tabel, iar interogările BM25, vectoriale sau hibride pot fi lansate din SQL; în plus, rerank() reordonează rezultatele de top folosind modelele de reranking Pinecone.

Documentația de pe docs.pinecone.io acoperă instalarea, motoarele de stocare, comutarea între motoare și căutarea full-text, iar depozitul de cod include și o referință SQL, un ghid operațional pentru operatori și un ghid de recuperare în caz de dezastru. Pinecone a descris aceasta drept prima versiune a proiectului, a declarat că întreține pg_pinecone și revizuiește fiecare solicitare de integrare și a spus că va construi foaia de parcurs publică pe baza feedbackului transmis prin problemele GitHub, comunitatea sa de pe Discord și sesiunile lunare de discuții cu echipa.