Databricks detaliază ramificarea Lakebase pentru agenți de codare paralelă

Databricks, pe 8 octombrie 2026, a publicat un articol de blog care detaliază un flux de dezvoltare în care fiecare agent de codare paralelă și fiecare solicitare de extragere rulează pe propria bază de date Postgres izolată și efemeră, creată prin ramificarea copy‑on‑write integrată în serviciul său de baze de date Lakebase.

În articol, Databricks descrie baza de date ca o parte adesea neglijată a fluxului de dezvoltare, la un moment în care agenții de codare preiau o pondere tot mai mare din munca de dezvoltare și rularea simultană a mai multor agenți devine norma. În mediile tradiționale partajate, cum ar fi o singură bază de date de dezvoltare sau de testare, agenții concurenți pot intra în conflict la modificările de schemă, se pot interfera reciproc sau pot recurge la simulări care nu reflectă datele din lumea reală. Acestea erau deja puncte dureroase pentru dezvoltatori, afirmă articolul, dar agenții le agravează deoarece se mișcă mai repede, operează în paralel și au nevoie de un mediu sigur care să evite punerea în pericol a datelor de producție sau expunerea datelor sensibile.

Mecanica ramificării

Databricks afirmă că ramificarea Lakebase permite utilizatorului să creeze o ramură a unei baze de date întregi în mai puțin de o secundă, indiferent de dimensiunea acesteia. Ramurile se bazează pe stocarea copy‑on‑write: o ramură nouă moștenește schema și datele părintelui său, împărtășind stocarea de bază și consumând spațiu suplimentar doar pe măsură ce diverge. Conform documentației privind ramificarea Lakebase a Databricks, fiecare proiect este creat cu o ramură implicită numită production, iar fiecare ramură, cu excepția ramurii rădăcină, are un părinte. Modificările într-o ramură copil nu afectează niciodată ramura părinte, iar izolarea se extinde la starea rolurilor Postgres: rolurile și bazele de date create, GRANT‑urile și REVOKE‑urile aplicate, și atributele de rol modificate într-o ramură nu au efect asupra celorlalte ramuri.

Fiecare ramură are propriul său calcul, se reduce la zero când este inactivă și este facturată doar pentru orele de calcul active, conform documentației. Facturarea stocării depinde de faptul dacă o ramură expiră: o ramură care expiră este facturată doar pentru datele modificate pe ea, în timp ce o ramură permanentă fără expirare este facturată pentru dimensiunea completă a datelor, ca o bază de date independentă. O resetare a ramurii, care reîmprospătează o ramură copil din părinte, funcționează într-o singură direcție, de la părinte la copil. Recuperarea în timp creează o nouă ramură rădăcină din date istorice în cadrul ferestrei de restaurare, lăsând ramura originală neschimbată și operațională.

Pe pagina sa de produs, Databricks descrie Lakebase ca un serviciu Postgres complet gestionat și fără server, care rulează motorul open‑source Postgres în loc de un fork.

O ramură pentru fiecare agent

Fluxul de lucru descris în articol asociază worktree‑urile Git cu ramurile Lakebase. Un worktree oferă fiecărui agent propriul său director cu ramura sa verificată, eliminând conflictele la nivel de fișier între agenți, iar un hook post‑checkout creează automat o ramură de bază de date pentru fiecare worktree nou. În exemplu, construit cu Claude Code, un agent rulează claude -worktree feature-123, Git creează worktree‑ul, hook‑ul se declanșează și agentul ajunge cu propriul director de cod și propria bază de date complet izolată. Fișierele de instrucțiuni ale depozitului, cum ar fi AGENTS.md sau CLAUDE.md, ghidează comportamentul agentului, iar când agentul termină, deschide o solicitare de extragere, după care atât worktree‑ul, cât și ramura bazei de date pot fi retrase.

Unul dintre diferențele față de Git, notează articolul, este că ramurile Lakebase nu sunt îmbinate înapoi în ramura principală, deoarece părinte și copil pot să se modifice independent și reconcilierea datelor lor poate deveni rapid impracticabilă. În schimb, modificările de schemă sunt urmărite în cod alături de logica aplicației și promovate în ramura părinte prin migrații, utilizând instrumente precum Drizzle, Flyway, Liquibase sau Alembic. Exemplul folosește Drizzle: când este necesară o modificare de schemă, agentul adaugă migrarea corespunzătoare în cod, iar automatizarea de implementare o aplică la lansarea aplicației de previzualizare și din nou când modificarea este îmbinată în principal.

O ramură pentru fiecare solicitare de extragere

Pentru integrare continuă, articolul descrie un flux de lucru GitHub Actions în care deschiderea unei solicitări de extragere împotriva ramurii principale declanșează Lakebase CLI pentru a crea o ramură efemeră, denumită după solicitarea de extragere, ca o ramură copil a ramurii de producție, iar acea ramură devine mediul de bază de date al solicitării de extragere. Instrumentul de migrare rulează pe noua ramură, o aplicație de previzualizare este implementată și direcționată către șirul de conexiune al ramurii, și se generează o diferență de schemă postată ca un comentariu la solicitarea de extragere, arătând exact ce tabele, coloane sau indici s-au modificat. Când solicitarea de extragere este închisă sau îmbinată, automatizarea șterge ramura. Deoarece ramura pornește din producție, migrarea de schemă poate fi aplicată și testată înainte ca modificarea să ajungă în producție. Exemplul implementează previzualizări pe Databricks Apps, deși articolul afirmă că conceptul se aplică și altor platforme de găzduire, cum ar fi Vercel, Netlify și Cloudflare.

În ceea ce privește mediile, articolul observă că o configurare obișnuită a Lakebase utilizează un spațiu de lucru Databricks pentru fiecare mediu, cum ar fi dezvoltare, testare și producție, și că echipele de obicei creează ramuri dintr-o bază de date inițială în loc de baza de date de producție pentru a evita expunerea datelor sensibile, cum ar fi PII. Demonstrația folosește un singur spațiu de lucru pentru simplitate, menționând totuși că aceleași concepte se aplică la configurări cu spații de lucru multiple.

Reproducerea erorilor și testarea migrațiilor

Dincolo de buclele per‑agent și per‑pull‑request, articolul descrie fluxuri de lucru cu ramuri care nu sunt implementate în depozitul de exemplu. Un dezvoltator poate crea o ramă izolată din producție la un moment specific în timp, de obicei chiar înainte de apariția unui bug, să reproducă și să investigheze problema pe date reale și să încheie ramura odată ce o corecție este validată. Echipele pot, de asemenea, să creeze o ramă înainte de a implementa în producție, să aplice o migrare de schemă, să ruleze teste și să verifice că aplicația se comportă în continuare conform așteptărilor înainte de a promova modificarea. Aceste fluxuri de lucru permit dezvoltatorilor să lucreze cu date asemănătoare producției sau derivate din producție, utilizând, de exemplu, mascare Unity Catalog, fără a expune baza de date live la risc, conform articolului.

Articolul conține un link către un depozit de exemplu pe GitHub, în directorul Lakebase-Agentic-CI al depozitului databricks/tmm, care conține exemple de fluxuri de lucru GitHub Actions ce implementează modelul. Concluzionează că, împreună, aceste modele formează ceea ce numește bucla de dezvoltare Lakebase: o ramă per agent, o ramă per pull request și ramuri izolate pentru validarea în producție.