Pinecone brengt Pg_pinecone uit, een opensource-extensie voor zoekopdrachten in Postgres

Pinecone bracht op 27 oktober 2026 pg_pinecone uit, een opensource-extensie voor Postgres onder de Apache 2.0-licentie. De extensie brengt de vectorzoekmachine waarvan het bedrijf zegt dat het die op grote schaal gebruikt naar de pgvector-kolommen die applicaties al opslaan. In benchmarks van het bedrijf was de native index voor 1 miljoen vectoren van 768 dimensies 136 MB groot, tegenover 2,0 GB voor HNSW op halfvec en 4,1 GB voor vectoren van volledige grootte.

De release werd aangekondigd in een aankondigingsbericht van Harshita Daddala en Anthony Mahanna. Volgens het bericht is een grafiekindex zoals HNSW de gebruikelijke manier om vectorzoekopdrachten in Postgres uit te voeren. Zo’n index heeft steeds meer geheugen nodig om goed te blijven presteren, is traag op te bouwen en levert minder nauwkeurige resultaten op bij zoekopdrachten met filters. Wanneer een zoekopdracht bijvoorbeeld beperkt is tot één gebruiker of tenant, kan een grafiekindex minder rijen teruggeven dan het opgegeven aantal in LIMIT. pg_pinecone past het filter tijdens het zoeken toe. Volgens Pinecone kan een beperkte zoekopdracht daardoor nog steeds een volledige reeks resultaten opleveren, terwijl de gegevens bij gebruik van de standaardengine binnen Postgres blijven.

Drie engines voor één index

pg_pinecone werkt met vector­kolommen die al in pgvector zijn opgeslagen. Een applicatie maakt op dezelfde manier verbinding met Postgres en verstuurt dezelfde SQL, bijvoorbeeld ORDER BY embedding <=> $1 LIMIT 10. De tabellen, inclusief de volledige vectoren, blijven op hun huidige plek en Postgres blijft de gezaghebbende gegevensbron.

Elke tabel gebruikt een van de drie engines. De native engine, de standaardoptie, bouwt de index volledig binnen Postgres op en doorzoekt die daar ook, zonder Pinecone-account, API-sleutel of netwerkverkeer. De pgvector-engine doorzoekt een bestaande pgvector-index, HNSW of IVFFlat. De GitHub-repository van het project beschrijft deze engine als geschikt voor tabellen die al een pgvector-index hebben en geen filters gebruiken. De externe engine stuurt zoekopdrachten naar een serverloze index in de beheerde dienst van Pinecone. Deze is bedoeld voor tabellen die de capaciteit van één Postgres-server zijn ontgroeid. Een tabel naar een andere engine omzetten kan met één aanroep van pinecone.set_engine(); de zoekopdrachten blijven ongewijzigd en elke overstap kan worden teruggedraaid.

Zo zoekt de native engine

Net als HNSW van pgvector gebruikt de native engine een algoritme dat bij benadering de dichtstbijzijnde buren vindt. In plaats van een graaf gebruikt de engine echter een inverted-file-index, die vergelijkbare vectoren in clusters groepeert. Elke vector wordt opgeslagen als een gekwantiseerde RaBitQ-code, met ongeveer één bit per dimensie plus enkele correctiewaarden. Volgens het bericht is deze methode afkomstig van Gao en Long, SIGMOD 2024. De codes van elk cluster worden bij elkaar opgeslagen, zodat een zoekopdracht enkele aaneengesloten pagina’s leest in plaats van door een graaf te springen.

Een zoekopdracht bestaat uit drie stappen: eerst worden de dichtstbijzijnde clusters geselecteerd door de queryvector met het zwaartepunt van elk cluster te vergelijken; vervolgens wordt voor elke rij op basis van de RaBitQ-code de geschatte afstand berekend en worden de beste kandidaten geselecteerd; ten slotte worden die kandidaten opnieuw gerangschikt aan de hand van hun volledige vectoren uit de tabel.

Filters worden tijdens het zoeken toegepast. Volgens Pinecone past pgvector bij HNSW achteraf filters toe: eerst worden de dichtstbijzijnde buren gevonden en daarna wordt de WHERE-clausule toegepast. Daardoor valt bij een nauw filter het grootste deel van de kandidaten af en vullen iteratieve scans de lijst weer aan, wat tijd kost en, bij gebruik van relaxed_order, de nauwkeurigheid verlaagt. De native engine slaat naast de code van elke rij de waarde van de filterkolom op en telt tijdens het opbouwen van de index hoeveel rijen elke waarde hebben. Bij nauwe filters, standaard 3% van de rijen of minder, past de engine het filter vooraf toe: hij scant alle overeenkomende rijen in alle clusters en beoordeelt ze aan de hand van hun volledige vector, zodat de resultaten exact zijn. Bij bredere filters gebruikt de engine filtering in één fase: hij doorzoekt maximaal de helft van de dichtstbijzijnde clusters en controleert het filter binnen elk cluster voordat de rijen worden beoordeeld.

Nieuwe invoegingen worden aan het dichtstbijzijnde cluster toegevoegd en zijn meteen doorzoekbaar. Omdat de zwaartepunten op hun oorspronkelijke plek blijven staan, adviseert het bericht na grote wijzigingen REINDEX uit te voeren of automatisch onderhoud in te schakelen, bijvoorbeeld nadat een bulklading de tabel twee keer zo groot heeft gemaakt. Zo worden de clusters opnieuw in balans gebracht.

Benchmarks van Pinecone

Pinecone vergeleek de native engine met de HNSW-index van pgvector, met vectoren van volledige grootte en halfvec, aan de hand van 1 miljoen wiki_dpr-vectoren van 768 dimensies. De tests werden uitgevoerd op een AWS r6id.4xlarge-instantie met 16 vCPU’s en 128 GB RAM. De latentie bij zoekopdrachten zonder filter, de bouwtijd en de indexgrootte werden in één sessie gemeten op PostgreSQL 17; zoekopdrachten met filters werden in een tweede sessie getest op PostgreSQL 18 en een configuratie met geheugenlimiet in een derde. De latentie wordt gerapporteerd als de mediane p50 bij k=10 met één client. Het bedrijf meldde dat de volledige testopstelling en de opdrachten om de tests opnieuw uit te voeren, zijn opgenomen in een README voor de benchmarkharnas in de repository.

Voor de 1 miljoen vectoren rapporteerde Pinecone een native index van 136 MB, tegenover 2,0 GB voor HNSW op halfvec en 4,1 GB voor vectoren van volledige grootte. Bij zoekopdrachten zonder filter rapporteerde het bedrijf een latentie van 1,3 ms bij een recall van 0,95, tegenover 1,7 ms voor HNSW op halfvec en 2,7 ms voor vectoren van volledige grootte. Bij een recall van 0,99 bedroeg de latentie 2,3 ms, tegenover respectievelijk 4,7 ms en 6,7 ms. Met een filter dat overeenkomt met 10% van de rijen rapporteerde Pinecone dat de native engine met filtering in één fase een recall van 1,000 behaalde in 12,3 ms, terwijl HNSW met iteratieve scans in 5,9 ms maximaal een recall van 0,920 behaalde. Bij een filter van 1% rapporteerde het bedrijf een recall van 0,981 in 8,3 ms. De gerapporteerde bouwtijd bedroeg 45 seconden voor de native engine, tegenover 62 seconden voor HNSW op halfvec en 79 seconden voor vectoren van volledige grootte.

Beschikbaarheid en optionele functies van Pinecone

pg_pinecone vereist PostgreSQL 17 of 18, superusertoegang en dat pgvector op de server is geïnstalleerd. De extensie kan worden geïnstalleerd vanuit vooraf gebouwde releases op GitHub of als de image pineconeteam/pg_pinecone op Docker Hub. Volgens de README is dit de image pgvector/pgvector met pg_pinecone eraan toegevoegd, gepubliceerd met één tag per hoofdversie van Postgres, zoals 0.11.0-pg17. Voor het uitvoeren van de engine op afstand moet de extensie ook worden geladen via shared_preload_libraries. Bij de installatie worden de extensies vector en pg_pinecone aangemaakt en wordt een index opgebouwd met een aanroep van pinecone.create_index(). Het project kan ook vanuit de broncode worden gebouwd met een Rust-toolchain en cargo-pgrx 0.19.2.

Met een optionele Pinecone API-sleutel synchroniseert de engine op afstand embeddings op de achtergrond met een Pinecone-index, terwijl zoekopdrachten in Postgres blijven lopen totdat het kopiëren is voltooid. Het bericht beschrijft nog drie optionele functies: met embed() roept u vanuit SQL de inferentieservice van Pinecone aan om tekst om te zetten in embeddings. Deze functie werkt met zowel de native engine als de engine op afstand en valt bij een eerste implementatie onder het gratis abonnement van Pinecone. BM25-zoeken in volledige tekst wordt naast vectorzoekopdrachten uitgevoerd op dezelfde tabel; vanuit SQL kunt u BM25-, vector- of hybride zoekopdrachten uitvoeren. Met rerank() worden de beste resultaten opnieuw gerangschikt met de rerankmodellen van Pinecone.

De documentatie op docs.pinecone.io behandelt de installatie, de opslagengines, het wisselen tussen engines en zoeken in volledige tekst. De repository bevat daarnaast een SQL-referentie, een draaiboek voor operators en een handleiding voor herstel na calamiteiten. Pinecone omschreef dit als de eerste release van het project, zei pg_pinecone te onderhouden en elke pull request te beoordelen, en gaf aan de openbare roadmap samen te stellen op basis van feedback via GitHub-issues, de Discord-community en maandelijkse spreekuren.