Databricks लाकबेस पोस्टग्रेज़ में पूर्ण‑पाठ और वेक्टर खोज लाता है

Databricks ने 28 सितंबर 2026 को Lakebase Search को प्रस्तुत किया, एक अंतर्निहित खोज इंजन जो उसके Lakebase Postgres डेटाबेस के लिए दो एक्सटेंशन के माध्यम से प्रदान किया जाता है: lakebaseवेक्टर निकटतम पड़ोसी खोज के लिए और lakebasetext BM25 पूर्ण‑पाठ खोज के लिए। दोनों एक्सटेंशन AWS और Azure पर सामान्य रूप से उपलब्ध हैं।

एक्सटेंशन डेवलपर्स को पोस्टग्रेज़ के भीतर सीधे ऑपरेशनल डेटा के साथ सेमेंटिक, कीवर्ड, और हाइब्रिड खोज चलाने की अनुमति देते हैं। Databricks ने कहा कि पारंपरिक OLTP सिस्टम AI एजेंटों की खोज आवश्यकताओं के लिए नहीं बनाए गए थे, जिन्हें कम विलंबता, उच्च‑शुद्धता पुनःप्राप्ति चाहिए और अक्सर बड़े पैमाने पर समानांतर खोजें चलानी पड़ती हैं, और अब तक इसका समाधान मुख्य डेटाबेस से एक स्टैंडअलोन खोज इंजन को ETL पाइपलाइन के साथ जोड़ना था। कंपनी ने कहा कि उसने Lakebase Search को सैकड़ों बीटा ग्राहकों की प्रतिक्रिया के साथ मिलाकर बनाया।

बेंचमार्क परिणाम और Conexiom तैनाती

Databricks ने कहा कि lakebase_वेक्टर VectorDBBench 100M बेंचमार्क पर अगले सर्वश्रेष्ठ सिस्टम की तुलना में दो गुना थ्रूपुट प्रदान करता है, जो LAION डेटासेट का उपयोग करता है, और यह क्लाउड पोस्टग्रेज़ विक्रेता द्वारा pgvector उपयोग करने की तुलना में चार गुना सस्ता है, ऑटोसकेलिंग से अतिरिक्त बचत से पहले। कंपनी ने 97% रिकॉल पर 71 मिलीसेकंड का P99 लेटेंसी रिपोर्ट किया, जिसका अर्थ है कि इंजन ने 97% समय में सही निकटतम पड़ोसियों को सफलतापूर्वक पुनःप्राप्त किया, और उल्लेख किया कि pgvector और DiskANN केवल एक बड़े इंस्टेंस पर परीक्षण किए गए थे।

Databricks ने Conexiom से एक ग्राहक परिणाम भी रिपोर्ट किया, जो अपने पहले के pgvector सेटअप की तुलना में आधे कंप्यूट फुटप्रिंट पर 100 मिलियन से अधिक पंक्तियों पर BM25 हाइब्रिड खोज चलाता है। कंपनी के अनुसार, Conexiom की इन्फ्रास्ट्रक्चर लागत तीन गुना घट गई और थ्रूपुट pgvector की तुलना में पाँच गुना बढ़ा।

“Lakebase Search हमें pgvector की तुलना में स्केलेबिलिटी का एक पूरी नई स्तर देता है, और उसी सर्वरलेस डेटाबेस में BM25 को अनलॉक करता है,” Conexiom में AI/ML आर्किटेक्ट Jordan Voves ने कहा। “हम स्केल पर अपने एजेंटों से डेटा को जोड़ने के लिए Lakebase का उपयोग करते हैं।”

डिज़ाइन के पीछे Pgvector सीमाएँ

Databricks ने कहा कि pgvector Lakebase Postgres में सबसे अधिक स्थापित एक्सटेंशन है, और उसने स्केल पर इसे चलाने वाले ग्राहकों से देखे गए तीन बार‑बार आने वाले दर्द बिंदुओं का वर्णन किया।

पहला है लागत, जो उपयोग के बजाय डेटा मात्रा के साथ स्केल करती है। pgvector अपना HNSW इंडेक्स डेटाबेस मेमोरी में रखता है, और क्योंकि HNSW खोज रैंडम‑एक्सेस ग्राफ ट्रैवर्सल पर निर्भर करती है, एक बार इंडेक्स डिस्क पर फैलने और क्वेरीज़ रैंडम रीड्स की श्रृंखला बन जाने पर प्रदर्शन 10 से 50 गुना तक गिर जाता है। 768‑आयामी float32 वेक्टर लगभग 3.3 किलोबाइट मेमोरी लेता है जब ग्राफ लिंक और Postgres ओवरहेड शामिल होते हैं, इसलिए 100 मिलियन पंक्तियों पर इंडेक्स को लगभग 330 गीगाबाइट RAM की आवश्यकता होती है जो क्वेरीज़ इसे छुएँ या न छुएँ, पूरी तरह प्रोविजन किया जाता है।

दूसरा है इंडेक्स रखरखाव। जब एक बिल्ड डिस्क पर फैल गया, तो pgvector इंडेक्स को मानक क्लाउड इंस्टेंस पर लगभग 50 घंटे लगते थे, Databricks ने कहा, और लिखावटें भी उसी बाधा से पीड़ित होती हैं क्योंकि वेक्टर डालने के लिए रैंडम‑एक्सेस ट्रैवर्सल और कई ग्राफ लेयरों में संशोधन आवश्यक होता है। चूंकि HNSW में कोई वैश्विक रीबैलेंसिंग नहीं है, खोज गुणवत्ता को पुनः प्राप्त करने के लिए पूर्ण REINDEX चलाना पड़ता है, जो तालिका को लॉक कर देता है और प्रोडक्शन लिखावटों को रोक देता है।

तीसरा यह है कि एकल क्वेरी को समानांतर नहीं किया जा सकता। एक pgvector क्वेरी एक Postgres बैकएंड प्रोसेस द्वारा निष्पादित होती है, जिससे HNSW इंडेक्स स्कैन में कोई समानांतरता नहीं रहती। रिकॉल बढ़ाने के लिए अधिक ग्राफ नोड्स का दौरा करना पड़ता है, जो रैंडम मेमोरी रीड्स और दूरी तुलना जोड़ते हैं, लेटेंसी बढ़ाते हैं और प्रति सेकंड क्वेरी की संख्या घटाते हैं, इसलिए थ्रूपुट को स्केल करने के लिए डेटाबेस कनेक्शन या रीड रेप्लिका जोड़ना आवश्यक है।

Lakebase_vector कैसे बनाया जाता है

Lakebase Postgres संग्रहण को कंप्यूट से अलग करता है: स्थायी डेटा कम लागत वाले क्लाउड ऑब्जेक्ट स्टोरेज में रहता है, जबकि RAM और स्थानीय NVMe अल्पकालिक कैश के रूप में कार्य करते हैं जो सक्रिय कार्य सेट को धारण करते हैं। इस बुनियाद के ऊपर, Databricks ने दो तकनीकों को मिलाया।

हायरार्किकल IVF क्लस्टरिंग वेक्टरों को क्लस्टरों में समूहित करता है जो निरंतर ब्लॉकों के रूप में संग्रहीत होते हैं। एक क्वेरी मेमोरी में क्लस्टर सेंट्रॉइड्स को स्कोर करती है, फिर केवल उन कुछ ब्लॉकों को पढ़ती है जो संभावित रूप से बड़े क्रमिक पढ़ने के रूप में आशाजनक दिखते हैं, बजाय कई रैंडम हॉप्स के। बाइनरी क्वांटाइजेशन, RaBitQ विधि का उपयोग करके, प्रत्येक वेक्टर को लगभग एक बिट प्रति आयाम तक संकुचित करता है, जो float32 से लगभग 32 गुना छोटा है, इसलिए क्वेरीज़ संक्षिप्त कोड स्कैन करती हैं ताकि उम्मीदवारों की शॉर्टलिस्ट बन सके और केवल उस शॉर्टलिस्ट को पूर्ण‑प्रिसिशन वेक्टरों के विरुद्ध पुनः रैंक किया जाए।

चूंकि डिज़ाइन स्टेटलेस है, यह शून्य तक स्केल करता है, और निष्क्रिय स्थिति में उपयोगकर्ता केवल संग्रहण के लिए भुगतान करते हैं। Databricks ने 100 मिलियन वेक्टर, 768‑आयामी डेटासेट पर स्केल‑टू‑ज़ीरो के बाद पहली क्वेरी के लिए मापा गया P90 1.13 सेकंड बताया, और कहा कि 100 मिलियन वेक्टर एक Lakebase Compute Unit पर सर्व किए जा सकते हैं।

इंडेक्स निर्माण क्लस्टर सेंट्रॉइड को एक बार छोटे रैंडम सैंपल पर प्रशिक्षित करता है; प्रत्येक वेक्टर को फिर उसके निकटतम सेंट्रॉइड को सौंपा जाता है, क्वांटाइज़ किया जाता है, और उपयुक्त ब्लॉक में एक स्वतंत्र ऑपरेशन के रूप में लिखा जाता है, इसलिए कार्य उपलब्ध कोरों की संख्या के अनुसार फैला रहता है। Databricks ने कहा कि उसकी LTAP आर्किटेक्चर इंडेक्स निर्माण को प्राथमिक डेटाबेस से Spark जैसे वितरित इंजन पर ऑफलोड करती है, जिससे निर्माण समय मिनटों में घट जाता है, और इस क्षमता पर और भी विकास आ रहा है। क्योंकि प्रेडिकेट ब्लॉक स्कैन के दौरान ही लागू होते हैं, फ़िल्टर किए गए क्वेरी उम्मीदवारों को अधिक फ़ेच करने से बचते हैं और रिकॉल उच्च रहता है, और एकल क्वेरी CPU कोरों में समानांतर चलती है।

BM25 टेक्स्ट सर्च और हाइब्रिड क्वेरीज़

Databricks ने कहा कि मानक Postgres tsvector सर्च में कॉर्पस-व्यापी प्रासंगिकता संदर्भ की कमी है। lakebase_text शब्दों को वैश्विक इनवर्स डॉक्यूमेंट फ्रिक्वेंसी के आधार पर स्कोर करता है, जिससे दुर्लभ, उच्च इरादे वाले शब्दों को अधिक वजन मिलता है और सामान्य भराव शब्दों को कम। यह इंडेक्स को ट्रैवर्स करते समय स्कोर की ऊपरी सीमा भी जांचता है, उन पूरे पोस्टिंग ब्लॉकों को त्याग देता है जो टॉप‑K परिणाम को प्रभावित नहीं कर सकते, जिसे कंपनी ने कहा कि यह GIN इंडेक्स वाले tsvector की तुलना में तेज़ बनाता है।

दोनों एक्सटेंशन को मिलाकर Postgres के भीतर मूल हाइब्रिड सर्च सक्षम होता है: एक ही क्वेरी सामान्य SQL फ़िल्टर प्रेडिकेट लागू कर सकती है, लाइव ऑपरेशनल टेबल्स को जॉइन कर सकती है, और सेमेंटिक वेक्टर स्कोरिंग को BM25 कीवर्ड प्रासंगिकता के साथ मिलाकर परिणाम दे सकती है। Databricks ने कहा कि सिस्टम एक पंक्ति से एक बिलियन वेक्टर तक और प्रति सेकंड एक क्वेरी से हजारों क्वेरी तक बिना मैनुअल रीप्रोविजनिंग के स्केल करता है, और इस डिज़ाइन को AI एजेंट्स के लिए बनाया गया बताया, जिनके वर्कफ़्लो सेकंडों में हजारों समवर्ती रिट्रीवल अनुरोध ट्रिगर कर सकते हैं।

Databricks Lakebase Search को उन उपयोगकर्ताओं के लिए स्थित करता है जो ऑपरेशनल और सर्च डेटा को एक ही डेटाबेस में एकीकृत करना चाहते हैं, जबकि Databricks AI Search अपने प्रबंधित इंजन के रूप में बॉक्स से बाहर काम करने वाली रिट्रीवल प्रदान करता है। Lakebase Search AWS और Azure पर सामान्य उपलब्ध है; मौजूदा Lakebase उपयोगकर्ता एक्सटेंशन सक्षम कर सकते हैं, और नए उपयोगकर्ता Lakebase के लिए साइन अप कर सकते हैं।