Databricks beskriver Lakebase-branching för parallella kodningsagenter

Databricks publicerade den 8 oktober 2026 ett blogginlägg som beskriver ett utvecklingsflöde där varje parallell kodningsagent och varje pull‑request körs mot sin egen isolerade, kortlivade Postgres‑databas, skapad via copy‑on‑write‑branching som är inbyggd i dess Lakebase-databasservice.

I inlägget beskriver Databricks databasen som en ofta förbises del av utvecklingsflödet i en tid då kodningsagenter tar på sig en växande andel av utvecklingsarbetet och att köra flera agenter parallellt blir normen. Med traditionella delade miljöer, såsom en enda utvecklings‑ eller staging‑databas, kan samtidiga agenter kollidera vid schemaändringar, störa varandra eller falla tillbaka på mockar som inte speglar verkliga data. Detta var redan smärtpunkter för utvecklare, enligt inlägget, men agenter förvärrar dem eftersom de rör sig snabbare, arbetar parallellt och behöver en säker miljö som undviker att produktionsdata riskeras eller känslig data exponeras.

Branchmekanik

Databricks säger att Lakebase‑branching låter en användare skapa en gren av en hel databas på under en sekund, oavsett storlek. Grenar bygger på copy‑on‑write‑lagring: en ny gren ärver förälderns schema och data samtidigt som den delar den underliggande lagringen och förbrukar extra lagring endast när den divergerar. Enligt Databricks’ dokumentation för Lakebase‑branching skapas varje projekt med en standardgren som heter production, och varje gren utom rotgrenen har en förälder. Ändringar i en barngren påverkar aldrig dess förälder, och isoleringen sträcker sig till Postgres‑rolltillstånd: roller och databaser som skapats, GRANT‑ och REVOKE‑kommandon som tillämpats, samt rollattribut som ändrats på en gren har ingen effekt på andra grenar.

Varje gren har sin egen beräkningskapacitet, skalas ner till noll när den är inaktiv och debiteras endast för aktiva beräkningstimmar, enligt dokumentationen. Lagringsdebitering beror på om en gren löper ut: en gren som löper ut debiteras endast för den data som förändrats på den, medan en permanent gren utan utgångsdatum debiteras för hela sin datamängd, som en fristående databas. En grenåterställning, som uppdaterar en barngren från sin förälder, fungerar endast i en riktning, från förälder till barn. Återställning till en viss tidpunkt skapar en ny rotgren från historisk data inom återställningsfönstret samtidigt som den ursprungliga grenen förblir oförändrad och i drift.

På dess produktsida beskriver Databricks Lakebase som en fullt hanterad, serverlös Postgres‑tjänst som kör den öppna källkods‑Postgres‑motorn snarare än en fork.

En gren per agent

Arbetsflödet i inlägget kombinerar Git‑arbetsträd med Lakebase‑grenar. Ett arbetsträd ger varje agent sin egen katalog med sin egen gren utcheckad, vilket eliminerar filnivåkonflikter mellan agenter, och en post‑checkout‑hook skapar sedan automatiskt en databasgren för varje nytt arbetsträd. I exemplet, byggt med Claude Code, kör en agent claude -worktree feature-123, Git skapar arbetsträdet, hooken triggas, och agenten får sin egen kodkatalog och sin egen fullständigt isolerade databas. Instruktionsfiler i repot, såsom AGENTS.md eller CLAUDE.md, styr agentens beteende, och när agenten är klar öppnar den en pull‑request, varefter både arbetsträdet och databasgrenen kan tas bort.

En skillnad mot Git, enligt inlägget, är att Lakebase‑grenar inte slås ihop med huvudgrenen, eftersom både förälder och barn kan ändras oberoende och att förena deras data snabbt kan bli opraktiskt. Istället spåras schemaändringar i koden tillsammans med applikationslogik och främjas till föräldragren via migrationer, med verktyg som Drizzle, Flyway, Liquibase eller Alembic. Exemplet använder Drizzle: när en schemaändring behövs lägger agenten till motsvarande migration i kodbasen, och driftsättningsautomatiseringen tillämpar den när förhandsgranskningsapplikationen distribueras och igen när ändringen slås ihop med main.

En gren per pull‑request

För kontinuerlig integration beskriver inlägget ett GitHub Actions‑arbetsflöde där öppning av en pull‑request mot main triggar Lakebase‑CLI att skapa en kortlivad gren, namngiven efter pull‑requesten, som ett barn till produktionsgrenen, och den grenen blir pull‑requestens databas‑miljö. Migreringsverktyget körs mot den nya grenen, en förhandsgranskningsapplikation distribueras och pekas mot grenens anslutningssträng, och en schema‑diff genereras och publiceras som en pull‑request‑kommentar som visar exakt vilka tabeller, kolumner eller index som ändrats. När pull‑requesten stängs eller slås ihop tar automatiseringen bort grenen. Eftersom grenen startar från produktion kan schema‑migrationen tillämpas och testas innan förändringen når produktion. Exemplet distribuerar förhandsgranskningar på Databricks Apps, men inlägget påpekar att konceptet gäller andra värdplattformar såsom Vercel, Netlify och Cloudflare.

När det gäller miljöer noterar inlägget att en vanlig Lakebase‑konfiguration använder ett Databricks‑arbetsutrymme per miljö, såsom utveckling, staging och produktion, och att team ofta branchar från en förberedd databas snarare än produktionsdatabasen för att undvika att exponera känslig data såsom PII. Genomgången använder ett enda arbetsutrymme för enkelhetens skull samtidigt som den påpekar att samma koncept gäller för flermiljö‑uppsättningar.

Felsökning och migreringstestning

Utöver per‑agent‑ och per‑pull‑request‑looparna beskriver inlägget greningsarbetsflöden som inte är implementerade i exempel‑repo‑t. En utvecklare kan skapa en isolerad gren från produktion vid en specifik tidpunkt, vanligtvis precis innan ett fel uppstod, reproducera och undersöka problemet mot verkliga data och avveckla grenen när en fix har validerats. Team kan också skapa en gren innan de distribuerar till produktion, tillämpa en schemamigrering, köra tester och verifiera att applikationen fortfarande beter sig som förväntat innan förändringen främjas. Dessa arbetsflöden låter utvecklare arbeta med produktionsliknande eller produktionshämtade data, till exempel med Unity Catalog‑maskering, utan att riskera den levande databasen, enligt inlägget.

Inlägget länkar till ett exempel‑repo på GitHub, i katalogen Lakebase-Agentic-CI i databricks/tmm‑repo‑t, som innehåller GitHub Actions‑arbetsflödesexempel som implementerar mönstret. Det sluts att dessa mönster tillsammans bildar det som kallas Lakebase‑utvecklingsloopen: en gren per agent, en gren per pull‑request och isolerade grenar för produktionsvalidering.