Databricks geeft details over Lakebase-branching voor parallelle code‑agents

Databricks heeft op 8 oktober 2026 een blogpost gepubliceerd waarin een ontwikkelworkflow wordt beschreven waarin elke parallelle code‑agent en elke pull‑request draait tegen zijn eigen geïsoleerde, tijdelijke Postgres‑database, die wordt aangemaakt via de copy‑on‑write‑branching die in zijn Lakebase-databaseservice is ingebouwd.

In de post beschrijft Databricks de database als een vaak over het hoofd gezien onderdeel van de ontwikkelworkflow op een moment dat code‑agents een steeds groter aandeel van het ontwikkelwerk op zich nemen en het draaien van meerdere agents parallel de norm wordt. Met traditionele gedeelde omgevingen, zoals een enkele ontwikkel‑ of staging‑database, kunnen gelijktijdige agents conflicteren over schema‑wijzigingen, elkaar hinderen, of terugvallen op mocks die geen realistische gegevens weergeven. Dit waren volgens de post al pijnpunten voor ontwikkelaars, maar agents verergeren ze omdat ze sneller bewegen, parallel opereren en een veilige omgeving nodig hebben die voorkomt dat productiedata in gevaar komt of gevoelige gegevens worden blootgesteld.

Branching‑mechanismen

Databricks stelt dat Lakebase‑branching een gebruiker in staat stelt een volledige database in minder dan een seconde te branchen, ongeacht de grootte. Branches maken gebruik van copy‑on‑write‑opslag: een nieuwe branch erft het schema en de data van zijn ouder terwijl ze de onderliggende opslag delen, en verbruikt extra opslag alleen wanneer ze divergeert. Volgens documentatie over Lakebase‑branching van Databricks wordt elk project aangemaakt met een standaardbranch genaamd production, en heeft elke branch behalve de root‑branch een ouder. Wijzigingen in een kind‑branch hebben nooit invloed op de ouder, en de isolatie strekt zich uit tot de Postgres‑rolstatus: rollen en databases die zijn aangemaakt, GRANT‑ en REVOKE‑acties, en rol‑attributen die op één branch worden aangepast, hebben geen effect op andere branches.

Elke branch heeft zijn eigen compute, schaalt naar nul wanneer idle, en wordt alleen gefactureerd voor actieve compute‑uren, stelt de documentatie. De opslagfacturering hangt af van of een branch verloopt: een vervallen branch wordt alleen gefactureerd voor de data die erop is gewijzigd, terwijl een permanente branch zonder vervaldatum wordt gefactureerd voor de volledige datagrootte, als een zelfstandige database. Een branch‑reset, die een kind‑branch van zijn ouder ververst, werkt slechts in één richting, van ouder naar kind. Point‑in‑time‑recovery maakt een nieuwe root‑branch aan uit historische data binnen het herstel‑venster, terwijl de oorspronkelijke branch onveranderd en operationeel blijft.

Op zijn productpagina beschrijft Databricks Lakebase als een volledig beheerde, serverloze Postgres‑service die de open‑source Postgres‑engine draait in plaats van een fork.

Een branch per agent

De workflow in de post koppelt Git‑worktrees aan Lakebase‑branches. Een worktree geeft elke agent zijn eigen map met een uitgecheckte branch, waardoor bestandsconflicten tussen agents verdwijnen, en een post‑checkout‑hook maakt vervolgens automatisch een database‑branch aan voor elke nieuwe worktree. In het voorbeeld, gebouwd met Claude Code, draait een agent claude -worktree feature-123, Git maakt de worktree aan, de hook wordt geactiveerd, en de agent krijgt zijn eigen code‑map en zijn eigen volledig geïsoleerde database. Repository‑instructiebestanden zoals AGENTS.md of CLAUDE.md sturen het gedrag van de agent aan, en wanneer de agent klaar is, opent hij een pull‑request, waarna zowel de worktree als de database‑branch kunnen worden beëindigd.

Een verschil met Git, merkt de post op, is dat Lakebase‑branches niet terug worden gemerged naar de hoofd‑branch, omdat ouder en kind onafhankelijk kunnen veranderen en het reconciliëren van hun data snel onpraktisch kan worden. In plaats daarvan worden schema‑wijzigingen in de code gevolgd naast de applicatielogica en naar de ouder‑branch gepromoveerd via migraties, met hulpmiddelen zoals Drizzle, Flyway, Liquibase of Alembic. Het voorbeeld maakt gebruik van Drizzle: wanneer een schema‑wijziging nodig is, voegt de agent de bijbehorende migratie toe aan de codebase, en past de deployment‑automatisering deze toe bij het uitrollen van de preview‑applicatie en opnieuw wanneer de wijziging naar main wordt gemerged.

Een branch per pull‑request

Voor continue integratie beschrijft de post een GitHub Actions‑workflow waarin het openen van een pull‑request tegen main de Lakebase‑CLI activeert om een tijdelijke branch aan te maken, genoemd naar de pull‑request, als kind van de production‑branch, en die branch wordt de database‑omgeving van de pull‑request. Het migratietool draait tegen de nieuwe branch, een preview‑applicatie wordt uitgerold en gekoppeld aan de verbindingsstring van de branch, en een schema‑diff wordt gegenereerd en als pull‑request‑commentaar geplaatst, waarin precies wordt getoond welke tabellen, kolommen of indexen zijn gewijzigd. Wanneer de pull‑request wordt gesloten of gemerged, verwijdert de automatisering de branch. Omdat de branch van production start, kan de schema‑migratie worden toegepast en getest voordat de wijziging production bereikt. Het voorbeeld rolt previews uit op Databricks Apps, hoewel de post aangeeft dat het concept van toepassing is op andere hostingplatformen zoals Vercel, Netlify en Cloudflare.

Wat omgevingen betreft, merkt de post op dat een veelvoorkomende Lakebase‑configuratie één Databricks‑workspace per omgeving gebruikt, zoals development, staging en production, en dat teams doorgaans branchten vanaf een vooraf gevulde database in plaats van de productiedatabase om te voorkomen dat gevoelige gegevens zoals PII worden blootgesteld. De walkthrough gebruikt één enkele workspace voor de eenvoud, terwijl wordt opgemerkt dat dezelfde concepten van toepassing zijn op multi‑workspace‑configuraties.

Bugreproductie en migratietesten

Buiten de per‑agent‑ en per‑pull‑request‑lussen beschrijft de post branching‑workflows die niet zijn geïmplementeerd in de voorbeeldrepository. Een ontwikkelaar kan een geïsoleerde tak van productie maken op een specifiek moment, meestal net voordat een bug optrad, het probleem reproduceren en onderzoeken met echte gegevens, en de tak beëindigen zodra een oplossing is gevalideerd. Teams kunnen ook een tak creëren vóór het uitrollen naar productie, een schema‑migratie toepassen, tests uitvoeren en verifiëren dat de applicatie zich nog steeds gedraagt zoals verwacht voordat de wijziging wordt gepromoveerd. Deze workflows stellen ontwikkelaars in staat om met productie‑achtige of uit productie afgeleide gegevens te werken, bijvoorbeeld met Unity Catalog masking, zonder de live‑database in gevaar te brengen, stelt de post.

De post verwijst naar een voorbeeldrepository op GitHub, in de Lakebase-Agentic-CI directory van de databricks/tmm repository, die GitHub Actions workflow‑voorbeelden bevat die het patroon implementeren. Hij concludeert dat deze patronen samen vormen wat hij de Lakebase development loop noemt: een tak per agent, een tak per pull‑request en geïsoleerde takken voor productieverificatie.