Databricks detaljerer Lakebase-branching for parallelle kodeagenter

Databricks publiserte 8. oktober 2026 en bloggpost som beskriver en utviklingsarbeidsflyt der hver parallelle kodeagent og hver pull request kjører mot sin egen isolerte, midlertidige Postgres-database, opprettet via copy‑on‑write‑branching som er innebygd i deres Lakebase-databasetjeneste.

I innlegget beskriver Databricks databasen som en ofte oversett del av utviklingsarbeidsflyten på et tidspunkt da kodeagenter tar på seg en stadig større andel av utviklingsarbeidet, og kjøring av flere agenter parallelt blir normen. Med tradisjonelle delte miljøer, som en enkelt utviklings‑ eller staging‑database, kan samtidige agenter komme i konflikt om skjemaendringer, forstyrre hverandre, eller falle tilbake på mock‑data som ikke gjenspeiler virkelige data. Dette var allerede smertepunkter for utviklere, hevder innlegget, men agenter forverrer dem fordi de beveger seg raskere, opererer parallelt, og trenger et trygt miljø som unngår å sette produksjonsdata i fare eller eksponere sensitiv informasjon.

Branching‑mekanismer

Databricks sier at Lakebase-branching gjør det mulig for en bruker å opprette en gren av en hel database på under ett sekund, uavhengig av størrelse. Grenene baserer seg på copy‑on‑write‑lagring: en ny gren arver foreldrenes skjema og data samtidig som den deler den underliggende lagringen, og bruker kun ekstra lagring etter hvert som den divergerer. I følge Databricks’ Lakebase branching-dokumentasjon blir hvert prosjekt opprettet med en standardgren kalt production, og alle grener bortsett fra rotgrenen har en forelder. Endringer i en undergren påvirker aldri dens forelder, og isolasjonen strekker seg til Postgres‑rolletilstand: roller og databaser som opprettes, GRANT‑ og REVOKE‑operasjoner som utføres, og rolleattributter som endres i én gren har ingen effekt på andre grener.

Hver gren har sin egen compute, skalerer ned til null når den er inaktiv, og faktureres kun for aktive compute‑timer, ifølge dokumentasjonen. Fakturering av lagring avhenger av om en gren utløper: en gren som utløper faktureres kun for data som endres på den, mens en permanent gren uten utløp faktureres for sin fulle datastørrelse, som en selvstendig database. En gren‑reset, som oppdaterer en undergren fra sin forelder, fungerer kun i én retning, fra forelder til undergren. Point‑in‑time‑gjenoppretting oppretter en ny rotgren fra historiske data innen gjenopprettingsvinduet, mens den opprinnelige grenen forblir uendret og i drift.

På sin produktside beskriver Databricks Lakebase som en fullt administrert, serverløs Postgres‑tjeneste som kjører den åpne kildekode‑Postgres‑motoren i stedet for en fork.

En gren per agent

Arbeidsflyten i innlegget kombinerer Git‑worktrees med Lakebase‑grener. En worktree gir hver agent sin egen katalog med sin egen gren sjekket ut, og fjerner filnivåkonflikter mellom agenter, mens en post‑checkout‑hook automatisk oppretter en databasegren for hver ny worktree. I eksemplet, bygget med Claude Code, kjører en agent claude -worktree feature-123, Git oppretter worktree‑en, hooken utløses, og agenten ender opp med sin egen kodekatalog og sin egen fullstendig isolerte database. Repository‑instruksjonsfiler som AGENTS.md eller CLAUDE.md veileder agentens oppførsel, og når agenten er ferdig åpner den en pull‑request, hvoretter både worktree‑en og databasegrenen kan avvikles.

En forskjell fra Git, bemerker innlegget, er at Lakebase‑grener ikke flettes tilbake til hovedgrenen, fordi både forelder og undergren kan endres uavhengig og samordning av dataene raskt kan bli upraktisk. I stedet spores skjemaendringer i koden sammen med applikasjonslogikken og fremmes til foreldregrenen via migrasjoner, ved bruk av verktøy som Drizzle, Flyway, Liquibase eller Alembic. Eksemplet bruker Drizzle: når en skjemaendring er nødvendig, legger agenten til den tilsvarende migrasjonen i kodebasen, og distribusjons‑automatiseringen anvender den ved utrulling av forhåndsvisningsapplikasjonen og igjen når endringen flettes inn i main.

En gren per pull request

For kontinuerlig integrasjon beskriver innlegget en GitHub Actions‑arbeidsflyt der åpning av en pull request mot main utløser Lakebase‑CLI til å opprette en midlertidig gren, navngitt etter pull request‑en, som et barn av produksjonsgrenen, og denne grenen blir pull request‑ens database‑miljø. Migrasjonsverktøyet kjører mot den nye grenen, en forhåndsvisningsapplikasjon distribueres og pekes mot grenens tilkoblingsstreng, og en skjema‑diff genereres og postes som en pull‑request‑kommentar som viser nøyaktig hvilke tabeller, kolonner eller indekser som endret seg. Når pull request‑en lukkes eller flettes, sletter automatiseringen grenen. Fordi grenen starter fra produksjon, kan skjema‑migrasjonen anvendes og testes før endringen når produksjon. Eksemplet distribuerer forhåndsvisninger på Databricks Apps, selv om innlegget hevder at konseptet gjelder for andre vertsplattformer som Vercel, Netlify og Cloudflare.

Når det gjelder miljøer, bemerker innlegget at en vanlig Lakebase‑oppsett bruker ett Databricks‑arbeidsområde per miljø, som utvikling, staging og produksjon, og at team vanligvis lager grener fra en seed‑database i stedet for produksjonsdatabasen for å unngå å eksponere sensitiv data som PII. Gjennomgangen bruker ett enkelt arbeidsområde for enkelhet, samtidig som den påpeker at de samme konseptene gjelder for oppsett med flere arbeidsområder.

Feilreproduksjon og migrasjonstesting

Utover per‑agent‑ og per‑pull‑request‑løkkene beskriver innlegget forgreningsarbeidsflyter som ikke er implementert i eksempel‑repoet. En utvikler kan opprette en isolert gren fra produksjon på et bestemt tidspunkt, vanligvis rett før en feil oppstod, gjenskape og undersøke problemet med ekte data, og avvikle grenen når en løsning er validert. Team kan også opprette en gren før utrulling til produksjon, anvende en skjema‑migrasjon, kjøre tester og verifisere at applikasjonen fortsatt oppfører seg som forventet før endringen blir promotert. Disse arbeidsflytene lar utviklere arbeide med produksjonslignende eller produksjonsavledede data, for eksempel ved bruk av Unity Catalog‑maskering, uten å sette den levende databasen i fare, ifølge innlegget.

Innlegget lenker til et eksempel‑repo på GitHub, i katalogen Lakebase-Agentic-CI i databricks/tmm‑repoet, som inneholder eksempler på GitHub Actions‑arbeidsflyter som implementerer mønsteret. Det konkluderer med at disse mønstrene sammen utgjør det innlegget kaller Lakebase‑utviklingsløkken: en gren per agent, en gren per pull‑request og isolerte greiner for produksjonsvalidering.