Pinecone ने Pg_pinecone जारी किया, जो ओपन-सोर्स Postgres सर्च एक्सटेंशन है

Pinecone ने 27 अक्टूबर 2026 को pg_pinecone जारी किया। यह Apache 2.0 लाइसेंस वाला ओपन-सोर्स Postgres एक्सटेंशन है, जो कंपनी के अनुसार बड़े पैमाने पर इस्तेमाल किए जाने वाले उसके वेक्टर सर्च इंजन को उन pgvector कॉलम में उपलब्ध कराता है, जिनमें ऐप्लिकेशन पहले से डेटा संग्रहित करते हैं। कंपनी के बताए बेंचमार्क में, 1 मिलियन 768-डाइमेंशन वेक्टर के लिए एक्सटेंशन का नेटिव इंडेक्स 136 MB का था, जबकि halfvec पर HNSW का आकार 2.0 GB और पूर्ण आकार वाले वेक्टर पर 4.1 GB था।

यह रिलीज़ Harshita Daddala और Anthony Mahanna द्वारा लिखी गई एक घोषणा पोस्ट में पेश की गई। पोस्ट के अनुसार, Postgres में वेक्टर सर्च चलाने का आम तरीका HNSW जैसे ग्राफ़ इंडेक्स का उपयोग करना है। प्रदर्शन बनाए रखने के लिए ऐसे इंडेक्स को लगातार अधिक मेमोरी की ज़रूरत पड़ती है, उन्हें बनाने में लंबा समय लगता है और फ़िल्टर की गई खोज में उनकी सटीकता घट जाती है। जब किसी क्वेरी का दायरा किसी एक उपयोगकर्ता या टेनेंट तक सीमित हो, तो ग्राफ़ इंडेक्स क्वेरी के LIMIT से कम पंक्तियाँ लौटा सकता है। इसके बजाय, pg_pinecone खोज के दौरान ही फ़िल्टर लागू करता है। Pinecone के अनुसार, इससे सीमित दायरे में भी परिणामों का पूरा सेट मिल सकता है; और इसके डिफ़ॉल्ट इंजन में डेटा कभी भी Postgres से बाहर नहीं जाता।

एक इंडेक्स के पीछे तीन इंजन

pg_pinecone, pgvector में पहले से मौजूद वेक्टर कॉलम के साथ काम करता है। ऐप्लिकेशन Postgres से उसी तरह जुड़ता है और वही SQL भेजता है, जैसे ORDER BY embedding <=> $1 LIMIT 10। इस दौरान पूरी तरह से वेक्टर सहित टेबल अपनी मौजूदा जगह पर रहते हैं और Postgres ही रिकॉर्ड का मुख्य स्रोत बना रहता है।

हर टेबल तीन में से किसी एक इंजन का इस्तेमाल करती है। डिफ़ॉल्ट नेटिव इंजन अपना इंडेक्स पूरी तरह Postgres के भीतर बनाता और खोजता है; इसके लिए Pinecone खाते, API key या नेटवर्क कॉल की ज़रूरत नहीं होती। pgvector इंजन किसी मौजूदा pgvector इंडेक्स—HNSW या IVFFlat—में खोज करता है। परियोजना की GitHub रिपॉज़िटरी के अनुसार, यह उन टेबल के लिए उपयुक्त है जिनमें पहले से pgvector इंडेक्स है और जिन पर फ़िल्टर नहीं लगाया जाता। रिमोट इंजन, Pinecone की प्रबंधित सेवा के सर्वरलेस इंडेक्स पर खोज भेजता है। यह उन टेबल के लिए है जो एक Postgres सर्वर की क्षमता से आगे बढ़ चुकी हैं। किसी टेबल का इंजन बदलने के लिए pinecone.set_engine() को एक बार कॉल करना होता है; क्वेरियाँ नहीं बदलतीं और हर बदलाव को वापस भी किया जा सकता है।

नेटिव इंजन कैसे खोज करता है

pgvector के HNSW की तरह, नेटिव इंजन भी लगभग निकटतम पड़ोसी खोजने वाला एल्गोरिदम इस्तेमाल करता है। लेकिन यह ग्राफ़ की जगह इनवर्टेड फ़ाइल इंडेक्स का उपयोग करता है, जो मिलते-जुलते वेक्टर को समूहों में बाँटता है। हर वेक्टर को क्वांटाइज़ किए गए RaBitQ कोड के रूप में संग्रहित किया जाता है—प्रत्येक डाइमेंशन के लिए लगभग एक बिट और साथ में कुछ सुधार मान। पोस्ट इस विधि का श्रेय Gao और Long, SIGMOD 2024 को देती है। हर समूह के कोड एक साथ पैक किए जाते हैं, इसलिए खोज के दौरान ग्राफ़ में इधर-उधर जाने के बजाय कुछ सन्निकट पेज पढ़ने पड़ते हैं।

खोज तीन चरणों में होती है: क्वेरी वेक्टर की तुलना हर समूह के सेंट्रॉइड से करके निकटतम समूहों की जाँच करना; हर पंक्ति के RaBitQ कोड से अनुमानित दूरी निकालना और सबसे अच्छे संभावित नतीजे चुनना; फिर टेबल में मौजूद उनके पूर्ण वेक्टर का इस्तेमाल करके उन नतीजों को दोबारा क्रम देना।

फ़िल्टरिंग खोज के दौरान ही होती है। Pinecone के अनुसार, pgvector का HNSW पहले निकटतम पड़ोसी खोजता है और उसके बाद WHERE क्लॉज़ लागू करता है। इससे सीमित फ़िल्टर अधिकांश संभावित नतीजों को हटा देता है और फिर इटरेटिव स्कैन समय की कीमत पर सूची को दोबारा भरते हैं; relaxed_order का उपयोग होने पर सटीकता भी घटती है। नेटिव इंजन हर पंक्ति के कोड के साथ फ़िल्टर-कॉलम का एक मान संग्रहित करता है और इंडेक्स बनाते समय हर मान वाली पंक्तियों की गिनती करता है। सीमित फ़िल्टर के लिए—डिफ़ॉल्ट रूप से 3% या उससे कम पंक्तियों पर लागू होने पर—यह पहले फ़िल्टर लगाता है। इसमें सभी समूहों में मेल खाने वाली हर पंक्ति को स्कैन किया जाता है और सटीक नतीजे पाने के लिए प्रत्येक का स्कोर उसके पूर्ण वेक्टर से निकाला जाता है। अधिक व्यापक फ़िल्टर के लिए यह एक-चरणीय फ़िल्टरिंग करता है: निकटतम समूहों में से अधिकतम आधे तक खोजता है और स्कोर निकालने से पहले हर समूह के भीतर फ़िल्टर जाँचता है।

नई प्रविष्टियाँ निकटतम समूह में जुड़ जाती हैं और तुरंत खोजी जा सकती हैं। चूँकि सेंट्रॉइड वहीं बने रहते हैं जहाँ उन्हें इंडेक्स बनाते समय रखा गया था, पोस्ट बड़े बदलावों के बाद REINDEX चलाने या स्वचालित रखरखाव सक्षम करने की सलाह देती है। ऐसा बदलाव टेबल में थोक लोड के कारण उसका आकार दोगुना होना भी हो सकता है। इससे समूहों का संतुलन फिर से ठीक हो जाता है।

Pinecone द्वारा बताए गए बेंचमार्क

Pinecone ने 768 डाइमेंशन वाले 1 मिलियन wiki_dpr वेक्टर पर पूर्ण आकार के वेक्टर और halfvec का उपयोग करते हुए नेटिव इंजन की तुलना pgvector के HNSW इंडेक्स से की। परीक्षण 16 vCPU और 128 GB RAM वाले AWS r6id.4xlarge इंस्टेंस पर किए गए। बिना फ़िल्टर वाली खोज की लेटेंसी, इंडेक्स बनाने का समय और इंडेक्स का आकार PostgreSQL 17 पर एक सत्र में मापा गया; फ़िल्टर वाली खोज PostgreSQL 18 पर दूसरे सत्र में और मेमोरी-सीमित कॉन्फ़िगरेशन तीसरे सत्र में मापा गया। लेटेंसी को एक क्लाइंट के साथ k=10 पर माध्यिका p50 के रूप में दर्ज किया गया। कंपनी ने बताया कि पूरी व्यवस्था और परीक्षणों को फिर से चलाने के कमांड, रिपॉज़िटरी की बेंचमार्क हार्नेस README में दिए गए हैं।

1 मिलियन वेक्टर के लिए Pinecone ने नेटिव इंडेक्स का आकार 136 MB बताया, जबकि halfvec पर HNSW का आकार 2.0 GB और पूर्ण आकार वाले वेक्टर पर 4.1 GB था। बिना फ़िल्टर वाली खोज में कंपनी ने 0.95 रिकॉल पर 1.3 ms की लेटेंसी बताई, जबकि halfvec पर HNSW के लिए यह 1.7 ms और पूर्ण आकार वाले वेक्टर पर 2.7 ms थी। 0.99 रिकॉल पर लेटेंसी क्रमशः 2.3 ms, 4.7 ms और 6.7 ms थी। 10% पंक्तियों से मेल खाने वाला फ़िल्टर लगाने पर Pinecone के अनुसार, नेटिव इंजन ने एक-चरणीय फ़िल्टरिंग के साथ 12.3 ms में 1.000 रिकॉल हासिल किया, जबकि इटरेटिव स्कैन वाले HNSW ने 5.9 ms में अधिकतम 0.920 रिकॉल हासिल किया। 1% फ़िल्टर के साथ कंपनी ने 8.3 ms में 0.981 रिकॉल दर्ज किया। इंडेक्स बनाने में नेटिव इंजन को 45 सेकंड लगे; इसकी तुलना में halfvec पर HNSW को 62 सेकंड और पूर्ण आकार वाले वेक्टर पर 79 सेकंड लगे।

उपलब्धता और Pinecone की वैकल्पिक सुविधाएँ

pg_pinecone के लिए PostgreSQL 17 या 18, सुपरयूज़र की पहुँच और सर्वर पर इंस्टॉल किया गया pgvector ज़रूरी है। इसे GitHub पर पहले से बनाए गए रिलीज़ से या Docker Hub पर pineconeteam/pg_pinecone इमेज के रूप में इंस्टॉल किया जा सकता है। README के अनुसार, यह pgvector/pgvector इमेज है, जिसमें pg_pinecone जोड़ा गया है। इसे प्रकाशित करते समय Postgres के हर मेजर वर्ज़न के लिए एक टैग दिया जाता है, जैसे 0.11.0-pg17। रिमोट इंजन चलाने के लिए shared_preload_libraries के ज़रिए एक्सटेंशन लोड करना भी ज़रूरी है। सेटअप के दौरान vector और pg_pinecone एक्सटेंशन बनाए जाते हैं और pinecone.create_index() कॉल से एक इंडेक्स तैयार किया जाता है। इस प्रोजेक्ट को Rust टूलचेन और cargo-pgrx 0.19.2 की मदद से सोर्स कोड से भी बनाया जा सकता है।

Pinecone API key वैकल्पिक रूप से जोड़ने पर, रिमोट इंजन बैकग्राउंड में एम्बेडिंग को Pinecone इंडेक्स के साथ सिंक करता है। कॉपी पूरी होने तक खोजें Postgres में चलती रहती हैं। पोस्ट में तीन अन्य वैकल्पिक सुविधाओं का भी ज़िक्र है: embed() कॉल SQL से टेक्स्ट को एम्बेडिंग में बदलने के लिए Pinecone की इन्फ़रेंस सेवा का उपयोग करता है, नेटिव और रिमोट—दोनों इंजनों के साथ काम करता है, और शुरुआती बिल्ड के लिए Pinecone के मुफ़्त प्लान में शामिल है; BM25 फ़ुल-टेक्स्ट सर्च उसी टेबल पर वेक्टर सर्च के साथ चलती है और SQL से BM25, वेक्टर या हाइब्रिड क्वेरी की जा सकती हैं; वहीं rerank() Pinecone के री-रैंकिंग मॉडल से शीर्ष नतीजों का क्रम बदलता है।

docs.pinecone.io पर उपलब्ध दस्तावेज़ों में इंस्टॉलेशन, स्टोरेज इंजन, इंजन बदलने और फ़ुल-टेक्स्ट सर्च की जानकारी है। इसके अलावा, रिपॉज़िटरी में SQL संदर्भ, ऑपरेटरों के लिए रनबुक और आपदा-पुनर्प्राप्ति मार्गदर्शिका भी शामिल हैं। Pinecone ने इसे प्रोजेक्ट की पहली रिलीज़ बताया, कहा कि वह pg_pinecone का रखरखाव करता है और हर पुल रिक्वेस्ट की समीक्षा करता है। उसने यह भी कहा कि GitHub इश्यू, अपने Discord समुदाय और मासिक कार्यालय समय के दौरान मिली प्रतिक्रियाओं के आधार पर सार्वजनिक रोडमैप तैयार किया जाएगा।