Databricks विवरण देता है Lakebase ब्रांचिंग को समानांतर कोडिंग एजेंट्स के लिए

Databricks ने 8 अक्टूबर, 2026 को एक ब्लॉग पोस्ट प्रकाशित किया, जिसमें एक विकास कार्यप्रवाह का विवरण दिया गया है जिसमें प्रत्येक समानांतर कोडिंग एजेंट और प्रत्येक पुल‑रिक्वेस्ट अपने स्वयं के अलग‑थलग, क्षणिक Postgres डेटाबेस पर चलता है, जो उसके Lakebase डेटाबेस सेवा में निर्मित कॉपी‑ऑन‑राइट ब्रांचिंग के माध्यम से बनाया गया है।

पोस्ट में, Databricks डेटाबेस को विकास कार्यप्रवाह का अक्सर‑अनदेखा किया जाने वाला भाग बताता है, जब कोडिंग एजेंट विकास कार्य का बढ़ता हिस्सा ले रहे हैं और कई एजेंटों को समानांतर चलाना सामान्य हो रहा है। पारंपरिक साझा वातावरणों, जैसे एकल विकास या स्टेजिंग डेटाबेस, के साथ, समवर्ती एजेंट स्कीमा परिवर्तन पर टकरा सकते हैं, एक‑दूसरे में हस्तक्षेप कर सकते हैं, या ऐसे मॉक पर निर्भर हो सकते हैं जो वास्तविक‑दुनिया के डेटा को प्रतिबिंबित नहीं करते। पोस्ट के अनुसार, ये पहले से ही डेवलपर्स के लिए दर्द बिंदु थे, लेकिन एजेंट इन्हें और बढ़ा देते हैं क्योंकि वे तेज़ चलते हैं, समानांतर काम करते हैं, और उन्हें एक सुरक्षित वातावरण चाहिए जो उत्पादन डेटा को जोखिम में न डालें या संवेदनशील डेटा को उजागर न करे।

ब्रांचिंग तंत्र

Databricks कहता है कि Lakebase ब्रांचिंग उपयोगकर्ता को पूरे डेटाबेस को एक सेकंड से कम समय में, उसके आकार की परवाह किए बिना, ब्रांच करने की अनुमति देती है। ब्रांचें कॉपी‑ऑन‑राइट स्टोरेज पर निर्भर करती हैं: एक नई ब्रांच अपने पैरेंट की स्कीमा और डेटा को विरासत में लेती है जबकि अंतर्निहित स्टोरेज को साझा करती है, और केवल तब अतिरिक्त स्टोरेज का उपभोग करती है जब वह विभेदित होती है। Databricks’ Lakebase ब्रांचिंग दस्तावेज़ के अनुसार, प्रत्येक प्रोजेक्ट को डिफ़ॉल्ट ब्रांच “production” नाम से बनाया जाता है, और मूल ब्रांच को छोड़कर हर ब्रांच का एक पैरेंट होता है। चाइल्ड ब्रांच में हुए परिवर्तन कभी भी उसके पैरेंट को प्रभावित नहीं करते, और यह अलगाव Postgres रोल स्थिति तक विस्तारित होता है: बनाए गए रोल और डेटाबेस, लागू किए गए GRANT और REVOKE, तथा एक ब्रांच में संशोधित रोल एट्रिब्यूट्स का अन्य ब्रांचों पर कोई प्रभाव नहीं पड़ता।

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

उसका उत्पाद पृष्ठ पर, Databricks Lakebase को एक पूरी तरह प्रबंधित, सर्वरलेस Postgres सेवा के रूप में वर्णित करता है जो फोर्क की बजाय ओपन‑सोर्स Postgres इंजन चलाती है।

प्रति एजेंट एक ब्रांच

पोस्ट में वर्णित कार्यप्रवाह Git वर्कट्रीज़ को Lakebase ब्रांचों के साथ जोड़ता है। एक वर्कट्री प्रत्येक एजेंट को उसकी अपनी डायरेक्टरी और उसकी अपनी चेक‑आउट की गई ब्रांच प्रदान करता है, जिससे एजेंटों के बीच फ़ाइल‑स्तर के टकराव समाप्त हो जाते हैं, और एक पोस्ट‑चेकआउट हुक स्वचालित रूप से प्रत्येक नई वर्कट्री के लिए एक डेटाबेस ब्रांच बनाता है। उदाहरण में, Claude Code के साथ निर्मित, एक एजेंट चलाता है claude -worktree feature-123Git वर्कट्री बनाता है, हुक सक्रिय होता है, और एजेंट को उसकी अपनी कोड डायरेक्टरी और पूरी तरह अलग‑थलग डेटाबेस मिल जाता है। रिपॉज़िटरी निर्देश फ़ाइलें जैसे AGENTS.md या CLAUDE.md एजेंट के व्यवहार को मार्गदर्शित करती हैं, और जब एजेंट समाप्त होता है तो वह एक पुल‑रिक्वेस्ट खोलता है, जिसके बाद वर्कट्री और डेटाबेस ब्रांच दोनों को समाप्त किया जा सकता है।

पोस्ट में बताया गया है कि Git से एक अंतर यह है कि Lakebase ब्रांचें मुख्य ब्रांच में वापस मर्ज नहीं की जातीं, क्योंकि पैरेंट और चाइल्ड दोनों स्वतंत्र रूप से बदल सकते हैं और उनके डेटा का मिलान जल्दी ही असंभव हो सकता है। इसके बजाय, स्कीमा परिवर्तन कोड में एप्लिकेशन लॉजिक के साथ ट्रैक किए जाते हैं और माइग्रेशन के माध्यम से पैरेंट ब्रांच में प्रोमोट किए जाते हैं, जैसे Drizzle, Flyway, Liquibase, या Alembic जैसे टूल्स का उपयोग करके। उदाहरण में Drizzle का उपयोग किया गया है: जब स्कीमा परिवर्तन की आवश्यकता होती है, तो एजेंट संबंधित माइग्रेशन को कोडबेस में जोड़ता है, और डिप्लॉयमेंट ऑटोमेशन इसे प्रीव्यू एप्लिकेशन को डिप्लॉय करते समय लागू करता है और फिर जब परिवर्तन मुख्य में मर्ज होता है।

प्रति पुल‑रिक्वेस्ट एक ब्रांच

लगातार इंटीग्रेशन के लिए, पोस्ट एक GitHub Actions कार्यप्रवाह प्रस्तुत करती है जिसमें मुख्य ब्रांच के विरुद्ध पुल‑रिक्वेस्ट खोलने से Lakebase CLI एक क्षणिक ब्रांच बनाता है, जिसका नाम पुल‑रिक्वेस्ट के नाम पर रखा जाता है, जो प्रोडक्शन ब्रांच की चाइल्ड होती है, और वह ब्रांच पुल‑रिक्वेस्ट का डेटाबेस वातावरण बन जाता है। माइग्रेशन टूल नई ब्रांच के विरुद्ध चलता है, एक प्रीव्यू एप्लिकेशन डिप्लॉय किया जाता है और ब्रांच के कनेक्शन स्ट्रिंग की ओर इशारा करता है, और एक स्कीमा डिफ़ उत्पन्न होकर पुल‑रिक्वेस्ट टिप्पणी के रूप में पोस्ट किया जाता है, जिसमें ठीक‑ठीक दिखाया जाता है कि कौन‑से टेबल, कॉलम या इंडेक्स बदलें। जब पुल‑रिक्वेस्ट बंद या मर्ज किया जाता है, तो ऑटोमेशन ब्रांच को हटा देता है। क्योंकि ब्रांच प्रोडक्शन से शुरू होती है, स्कीमा माइग्रेशन को परिवर्तन प्रोडक्शन तक पहुँचने से पहले लागू और परीक्षण किया जा सकता है। उदाहरण Databricks Apps पर प्रीव्यू डिप्लॉय करता है, हालांकि पोस्ट कहती है कि यह अवधारणा अन्य होस्टिंग प्लेटफ़ॉर्म जैसे Vercel, Netlify, और Cloudflare पर भी लागू होती है।

पर्यावरणों के बारे में, पोस्ट बताती है कि सामान्य Lakebase सेटअप प्रत्येक पर्यावरण के लिए एक Databricks वर्कस्पेस का उपयोग करता है, जैसे विकास, स्टेजिंग, और प्रोडक्शन, और टीमें अक्सर प्रोडक्शन डेटाबेस के बजाय एक सीडेड डेटाबेस से ब्रांच करती हैं ताकि संवेदनशील डेटा जैसे PII को उजागर करने से बचा जा सके। यह walkthrough सरलता के लिए एकल वर्कस्पेस का उपयोग करता है जबकि यह नोट करता है कि वही अवधारणाएँ मल्टी‑वर्कस्पेस सेटअप पर भी लागू होती हैं।

बग पुनरुत्पादन और माइग्रेशन परीक्षण

प्रति‑एजेंट और प्रति‑पुल‑रिक्वेस्ट लूप्स के अलावा, इस पोस्ट में उन ब्रांचिंग वर्कफ़्लोज़ का वर्णन किया गया है जो उदाहरण रिपॉज़िटरी में लागू नहीं किए गए हैं। एक डेवलपर उत्पादन से एक विशिष्ट समय बिंदु पर, आमतौर पर बग के प्रकट होने से ठीक पहले, एक अलग ब्रांच बना सकता है, वास्तविक डेटा के विरुद्ध समस्या को पुनः उत्पन्न कर जांच सकता है, और फ़िक्स की पुष्टि होने पर ब्रांच को समाप्त कर सकता है। टीमें उत्पादन में डिप्लॉय करने से पहले भी एक ब्रांच बना सकती हैं, स्कीमा माइग्रेशन लागू कर सकती हैं, परीक्षण चला सकती हैं, और परिवर्तन को प्रमोट करने से पहले यह सत्यापित कर सकती हैं कि एप्लिकेशन अभी भी अपेक्षित रूप से कार्य कर रहा है। ये वर्कफ़्लोज़ डेवलपर्स को उत्पादन‑समान या उत्पादन‑उत्पन्न डेटा के साथ काम करने की अनुमति देते हैं, उदाहरण के तौर पर Unity Catalog मास्किंग का उपयोग करके, बिना लाइव डेटाबेस को जोखिम में डाले, जैसा कि पोस्ट में कहा गया है।

पोस्ट GitHub पर एक उदाहरण रिपॉज़िटरी का लिंक देती है, जो databricks/tmm रिपॉज़िटरी के Lakebase-Agentic-CI डायरेक्टरी में स्थित है, और इसमें पैटर्न को लागू करने वाले GitHub Actions वर्कफ़्लो उदाहरण शामिल हैं। यह निष्कर्ष निकालती है कि ये पैटर्न मिलकर वह Lakebase विकास लूप बनाते हैं जिसे वह Lakebase development loop कहता है: प्रति एजेंट एक ब्रांच, प्रति पुल‑रिक्वेस्ट एक ब्रांच, और उत्पादन सत्यापन के लिए अलग‑अलग ब्रांच।