Databricks beskriver Lakebase-branching for parallelle kodeagenter

Databricks offentliggjorde den 8. oktober 2026 et blogindlæg, som beskriver en udviklingsarbejdsgang, hvor hver parallel kodeagent og hver pull‑request kører mod sin egen isolerede, kortvarige Postgres-database, oprettet gennem copy‑on‑write‑branching, som er indbygget i deres Lakebase databasetjeneste.

I indlægget beskriver Databricks databasen som en ofte overset del af udviklingsarbejdsprocessen på et tidspunkt, hvor kodeagenter påtager sig en voksende andel af udviklingsarbejdet, og kørsel af flere agenter parallelt bliver normen. Med traditionelle delte miljøer, såsom en enkelt udviklings‑ eller staging‑database, kan samtidige agenter komme i konflikt om schemaændringer, forstyrre hinanden eller falde tilbage på mock‑data, som ikke afspejler virkelige data. Ifølge indlægget var dette allerede smertepunkter for udviklere, men agenter forværrer dem, fordi de bevæger sig hurtigere, opererer parallelt og har brug for et sikkert miljø, der undgår at sætte produktionsdata i fare eller afsløre følsomme data.

Branching‑mekanik

Databricks siger, at Lakebase-branching lader en bruger branchere en hel database på under ét sekund, uanset størrelsen. Brancher bygger på copy‑on‑write‑lagring: en ny gren arver sin forælders schema og data, mens den deler den underliggende lagring og kun forbruger yderligere lager, når den divergerer. Ifølge Databricks’ Lakebase branch-dokumentation oprettes hvert projekt med en standardgren kaldet production, og hver gren undtagen rodgrenen har en forælder. Ændringer i en undergren påvirker aldrig dens forælder, og isolation udvides til Postgres‑rolle‑tilstand: roller og databaser oprettet, GRANTs og REVOKEs anvendt, samt rolle‑attributter ændret på én gren har ingen effekt på andre grene.

Hver gren har sin egen compute, skalerer ned til nul, når den er inaktiv, og faktureres kun for aktive compute‑timer, ifølge dokumentationen. Fakturering af lager afhænger af, om en gren udløber: en udløbende gren faktureres kun for de data, der ændres på den, mens en permanent gren uden udløb faktureres for sin fulde datastørrelse, som en selvstændig database. En gren‑nulstilling, som opdaterer en undergren fra dens forælder, fungerer kun i én retning, fra forælder til barn. Point‑in‑time‑gendannelse opretter en ny rodgren fra historiske data inden for gendannelses‑vinduet, mens den oprindelige gren forbliver uændret og i drift.

På dens produktside beskriver Databricks Lakebase som en fuldt administreret, serverløs Postgres‑tjeneste, der kører den open‑source Postgres‑motor i stedet for en fork.

En gren pr. agent

Arbejdsgangen i indlægget parrer Git‑worktrees med Lakebase‑grene. Et worktree giver hver agent sit eget bibliotek med sin egen gren tjekket ud, hvilket fjerner fil‑niveau konflikter mellem agenter, og et post‑checkout‑hook opretter derefter automatisk en databasegren for hvert nyt worktree. I eksemplet, bygget med Claude Code, kører en agent claude -worktree feature-123, Git opretter worktree’et, hook’en udløses, og agenten ender med sit eget kodebibliotek og sin egen fuldt isolerede database. Repository‑instruktionsfiler såsom AGENTS.md eller CLAUDE.md guider agentens adfærd, og når agenten er færdig, åbner den en pull‑request, hvorefter både worktree’et og databasegrenen kan pensioneres.

En forskel fra Git, bemærker indlægget, er at Lakebase‑grene ikke flettes tilbage til hovedgrenen, fordi både forælder og barn kan ændre sig uafhængigt, og sammenlægning af deres data hurtigt kan blive upraktisk. I stedet spores schemaændringer i koden sammen med applikationslogik og promoveres til forældergrenen via migrationer, ved brug af værktøjer såsom Drizzle, Flyway, Liquibase eller Alembic. Eksemplet bruger Drizzle: når en schemaændring er nødvendig, tilføjer agenten den tilsvarende migration til kodebasen, og implementeringsautomatiseringen anvender den ved udrulning af preview‑applikationen og igen, når ændringen flettes ind i main.

En gren pr. pull‑request

For kontinuerlig integration beskriver indlægget et GitHub Actions‑workflow, hvor åbning af en pull‑request mod main udløser Lakebase‑CLI’en til at oprette en midlertidig gren, navngivet efter pull‑requesten, som et barn af produktionsgrenen, og den gren bliver pull‑requestens database‑miljø. Migration‑værktøjet kører mod den nye gren, en preview‑applikation udrulles og peges på grenens forbindelsesstreng, og en schema‑diff genereres og postes som en pull‑request‑kommentar, der viser præcis hvilke tabeller, kolonner eller indekser der er ændret. Når pull‑requesten lukkes eller flettes, sletter automatiseringen grenen. Da grenen starter fra produktion, kan schema‑migrationen anvendes og testes, før ændringen når produktion. Eksemplet udruller previews på Databricks Apps, selvom indlægget angiver, at konceptet gælder for andre hosting‑platforme såsom Vercel, Netlify og Cloudflare.

Ved miljøer bemærker indlægget, at en almindelig Lakebase‑opsætning bruger én Databricks‑workspace pr. miljø, såsom udvikling, staging og produktion, og at teams typisk brancher fra en forudfyldt database i stedet for produktionsdatabasen for at undgå at eksponere følsomme data såsom PII. Gennemgangen bruger én enkelt workspace for enkelhed, mens den påpeger, at de samme koncepter gælder for opsætninger med flere workspaces.

Fejlreproduktion og migrationstest

Udover de per‑agent‑ og per‑pull‑request‑sløjfer beskriver indlægget forgrening‑arbejdsprocesser, som ikke er implementeret i eksempel‑lageret. En udvikler kan oprette en isoleret gren fra produktionen på et bestemt tidspunkt, typisk lige før en fejl opstod, reproducere og undersøge problemet med rigtige data og afvikle grenen, når en rettelse er bekræftet. Teams kan også oprette en gren inden de deployerer til produktion, anvende en schemas‑migration, køre tests og bekræfte, at applikationen stadig opfører sig som forventet, før ændringen promoveres. Disse arbejdsprocesser gør det muligt for udviklere at arbejde med produktionslignende eller produktionsafledte data, for eksempel ved brug af Unity Catalog‑maskering, uden at bringe den levende database i fare, skriver indlægget.

Indlægget linker til et eksempel‑lager på GitHub, i Lakebase-Agentic-CI‑mappen i databricks/tmm‑lageret, som indeholder GitHub Actions‑workflow‑eksempler, der implementerer mønsteret. Det konkluderer, at disse mønstre samlet udgør det, der kaldes Lakebase‑udviklingsløkken: en gren per agent, en gren per pull‑request og isolerede grene til produktionsvalidering.