Pinecone brengt pg_pinecone uit voor PostgreSQL

Pinecone brengt pg_pinecone als Apache 2.0-extensie uit voor vectorzoekwerk op bestaande pgvector-kolommen in PostgreSQL, zo kondigde het bedrijf op 27 oktober aan.

Teams die RAG op PostgreSQL bouwen kunnen de vectorindex hiermee in dezelfde database houden. De dataroute hangt af van de enginekeuze. De standaard zoekt binnen PostgreSQL zonder netwerkverbinding. De externe engine synchroniseert embeddings naar Pinecone en voert zoekwerk daar uit.

De extensie kiest waar zoeken draait

pg_pinecone werkt met vector-kolommen die al via pgvector in PostgreSQL staan. De toepassing blijft dezelfde SQL-query sturen. Per tabel kan de beheerder kiezen uit drie engines. De projectdocumentatie beschrijft de drie engines achter dezelfde kolommen en query's. Installatie vraagt PostgreSQL 17 of 18, superuserrechten en pgvector.

De standaardengine, native, bouwt en doorzoekt de index volledig in PostgreSQL. Daarvoor zijn geen Pinecone-account, API-sleutel of netwerkoproepen nodig. De tabellen en volledige vectoren blijven in de database. De pgvector-engine gebruikt een bestaande HNSW- of IVFFlat-index. De remote-engine stuurt zoekopdrachten naar een serverless index van Pinecone en synchroniseert embeddings op de achtergrond. Tot de kopie klaar is, blijven zoekopdrachten via PostgreSQL lopen. PostgreSQL blijft de bron van waarheid. Wisselen kan met één SQL-aanroep, zonder de query van de toepassing te veranderen.

Met een Pinecone API-sleutel zijn ook extra functies beschikbaar. embed() maakt vectoren vanuit tekst via Pinecone's inference-service. BM25 zoekt op exacte woorden naast zoeken op betekenis. rerank() herschikt gevonden passages met een Pinecone-model. Zo brengt de extensie meer onderdelen van een RAG-keten naar SQL. Elk onderdeel heeft wel een eigen datastroom. Alleen native zoeken blijft binnen PostgreSQL; embed() en rerank() voegen externe Pinecone-verzoeken toe.

Pinecone rapporteert kleinere index en hogere filterrecall

Voor een miljoen vectoren van 768 dimensies rapporteert Pinecone een native index van 136 MB. HNSW op halfvec nam in dezelfde test 2,0 GB in; op vectoren met volledige precisie was dat 4,1 GB. De native index werd gebouwd in 45 seconden, tegenover 62 seconden voor HNSW op halfvec en 79 seconden voor volledige vectoren. Bij een zoekopdracht zonder filter noteerde Pinecone 1,3 milliseconde bij 0,95 recall. Recall meet hoeveel van de dichtstbijzijnde resultaten worden teruggevonden. HNSW op halfvec kwam op 1,7 milliseconde en HNSW op volledige vectoren op 2,7 milliseconde. Bij 0,99 recall waren de tijden respectievelijk 2,3, 4,7 en 6,7 milliseconde.

Het verschil wordt concreet bij een filter op klant of tenant. Als 1 procent van de regels aan het filter voldoet, rapporteert Pinecone voor native 0,981 recall in 8,3 milliseconde. HNSW op halfvec kwam op 0,924 in 56 milliseconde. Bij een filter dat 10 procent van de regels overlaat, haalde native 1,000 recall in 12,3 milliseconde. HNSW met iteratieve scans haalde in die meting maximaal 0,920 recall in 5,9 milliseconde. In die test vond native meer relevante resultaten; HNSW werkte sneller.

De index vormt één laag van een RAG-keten

Een RAG-keten kan PostgreSQL met pgvector als vectordatabase combineren met embeddings, hybride zoeken, reranking en een eigen vragenset. pg_pinecone verandert de zoekindex. De toepassingslaag bepaalt welke documenten worden geïndexeerd, welke passages een medewerker mag zien en hoe vaak bronnen worden bijgewerkt.

De embeddingkeuze staat los van de index. Google bracht EmbeddingGemma 2 uit, dat tekst, code, beeld, video en audio omzet naar vectoren in één ruimte van 768 dimensies. Dat model maakt vectoren; pg_pinecone slaat ze op en doorzoekt ze. De RAG-opzet bestaat dus uit losse onderdelen: model, index, toegangscontrole, zoekfilter en antwoordmodel. De keuze voor native houdt volledige records binnen PostgreSQL. Embeddings en reranking kunnen via aparte Pinecone-functies lopen.

De benchmarks hebben een smalle meetbasis

De vergelijkingen komen van Pinecone zelf. Het openbare benchmarkharnas beschrijft configuraties en commando's om vectorzoektests opnieuw uit te voeren. De test gebruikt één miljoen wiki_dpr-vectoren van 768 dimensies. Pinecone noemt een AWS r6id.4xlarge met 16 vCPU's en 128 GB geheugen. De latentie is de mediaan (p50) bij k=10 met één client. De metingen zijn verdeeld over PostgreSQL 17 en 18. De resultaten tonen niet hoe de index presteert op Nederlandse bedrijfsdata of bij veel gelijktijdige gebruikers.

HNSW-filtering is instelbaar. De pgvector-documentatie beschrijft iteratieve scans die vanaf versie 0.8.0 verder zoeken wanneer een filter te weinig resultaten overlaat. Instellingen voor het aantal te doorzoeken regels en het geheugengebruik begrenzen die scan. In een eigen dataset kunnen querymix, tenantverdeling, indexgrootte en gelijktijdige gebruikers de uitkomst veranderen. Na grote wijzigingen adviseert Pinecone REINDEX of automatisch onderhoud. Voorbeelden zijn een bulktoevoeging die de tabel verdubbelt of sterk veranderde gegevens.

Voor teams die PostgreSQL al gebruiken, maakt pg_pinecone de enginekeuze verwisselbaar zonder de SQL-query te herschrijven. Per tabel kan zoeken binnen PostgreSQL blijven of naar de beheerde Pinecone-dienst verhuizen. De keuze hangt af van wat de databasehost toestaat, hoe eigen filters presteren en welke delen van de RAG-keten Pinecone mogen aanroepen.