Databricks esittelee Lakebase-haarautumisen rinnakkaisille koodausagenteille

Databricks julkaisi 8. lokakuuta 2026 blogikirjoituksen, jossa kerrotaan kehitysprosessista, jossa jokainen rinnakkainen koodausagentti ja jokainen pull request käyttää omaa eristettyä, tilapäistä Postgres-tietokantaa, joka luodaan copy‑on‑write‑haaran avulla, joka on sisäänrakennettu sen Lakebase-tietokantapalveluun.

Julkaisussa Databricks kuvaa tietokantaa usein huomiotta jääneeksi osaksi kehitysprosessia aikana, jolloin koodausagentit ottavat yhä suuremman osan kehitystyöstä ja useiden agenttien ajaminen rinnakkain on tavanomaista. Perinteisissä jaetuissa ympäristöissä, kuten yhdessä kehitys‑ tai testitietokannassa, samanaikaiset agentit voivat törmätä skeemamuutoksiin, häiritä toisiaan tai turvautua mokkeihin, jotka eivät vastaa todellista dataa. Nämä olivat jo kehittäjille kipupisteitä, julkaisun mukaan, mutta agentit pahentavat tilannetta, koska ne liikkuvat nopeammin, toimivat rinnakkain ja tarvitsevat turvallisen ympäristön, joka estää tuotantodatan vaarantumisen tai arkaluontoisen tiedon paljastumisen.

Haarautumisen mekanismi

Databricksin mukaan Lakebase-haarautus mahdollistaa koko tietokannan haarauttamisen alle sekunnissa, koosta riippumatta. Haarat perustuvat copy‑on‑write‑tallennukseen: uusi haara perii vanhemman skeeman ja datan samalla jakaen taustatallennuksen, ja kuluttaa lisätilaa vain poikkeavuuksien mukaan. Databricksin Lakebase-haaran dokumentaatio mukaan jokainen projekti luodaan oletushaaralla nimeltä production, ja kaikilla haaroilla, paitsi juurihaaralla, on vanhempi. Lapsihaaran muutokset eivät koskaan vaikuta sen vanhempaan, ja eristys ulottuu myös Postgres‑roolitilaan: roolit ja tietokannat, jotka on luotu, GRANT‑ ja REVOKE‑komennot, sekä rooliattribuutit, jotka on muutettu yhdessä haarassa, eivät vaikuta muihin haaroihin.

Jokaisella haaralla on oma laskentaympäristönsä, se skaalaa nollaan ollessaan käyttämättömänä, ja siitä veloitetaan vain aktiivisista laskentatunneista, dokumentaation mukaan. Tallennuksen hinnoittelu riippuu siitä, vanheneeko haara: vanheneva haara veloitetaan vain sen muuttamasta datasta, kun taas pysyvä haara ilman vanhenemista veloitetaan koko datamäärästään, kuten itsenäinen tietokanta. Haara‑reset, joka päivittää lapsihaaran vanhemmasta, toimii vain yhteen suuntaan, vanhemmasta lapseen. Aikakohtainen palautus luo uuden juurihaaran historiallisesta datasta palautusikkunan sisällä jättäen alkuperäisen haaran muuttumattomaksi ja toiminnalliseksi.

Sen tuotesivulla Databricks kuvaa Lakebasea täysin hallittuna, serverittömänä Postgres‑palveluna, joka käyttää avoimen lähdekoodin Postgres‑moottoria eikä haarautunutta versiota.

Yksi haara per agentti

Julkaisun työnkulku yhdistää Git‑työpuut Lakebase‑haaroihin. Työpuu antaa jokaiselle agentille oman hakemiston, jossa on oma haara tarkistettuna, poistaen tiedostotasoiset ristiriidat agenttien välillä, ja post‑checkout‑koukku luo automaattisesti tietokantahaaran jokaiselle uudelle työpuulle. Esimerkissä, joka on rakennettu Claude Code‑työkalulla, agentti suorittaa claude -worktree feature-123, Git luo työpuun, koukku käynnistyy, ja agentti saa oman koodihakemistonsa sekä täysin eristetyn tietokannan. Repo‑ohjetiedostot, kuten AGENTS.md tai CLAUDE.md, ohjaavat agentin toimintaa, ja kun agentti on valmis, se avaa pull‑requestin, jonka jälkeen sekä työpuu että tietokantahaara voidaan poistaa.

Yksi ero Gitistä, jonka mukaan artikkeli toteaa, on se, että Lakebase‑haaroja ei yhdistetä takaisin päähaaraan, koska sekä vanhempi että lapsi voivat muuttua itsenäisesti ja niiden datan sovittaminen voi nopeasti käydä epäkäytännölliseksi. Sen sijaan skeemamuutokset seurataan koodissa sovelluslogiikan rinnalla ja ne siirretään vanhempaan haaraan migraatioiden avulla, käyttäen työkaluja kuten Drizzle, Flyway, Liquibase tai Alembic. Esimerkissä käytetään Drizzleä: kun skeemamuutos on tarpeen, agentti lisää vastaavan migraation koodikantaan, ja käyttöönotto‑automaatiot toteuttaa sen sekä esikatselu‑sovelluksen käyttöönotossa että kun muutos yhdistyy päähaaraan.

Yksi haara per pull‑request

Jatkuvaa integraatiota varten artikkeli esittelee GitHub Actions -työnkulun, jossa pull‑requestin avaaminen päähaaraan käynnistää Lakebase‑CLI:n luomaan tilapäisen haaran, jonka nimi on pull‑requestin mukaan, lapsena tuotantohaarassa, ja tämä haara toimii pull‑requestin tietokanta‑ympäristönä. Migraatiotyökalu ajetaan uudessa haarassa, esikatselu‑sovellus otetaan käyttöön ja ohjataan haaran yhteysmerkkijonoon, ja skeemadiffi luodaan ja julkaistaan pull‑request‑kommenttina, jossa näytetään tarkalleen, mitkä taulut, sarakkeet tai indeksit muuttuvat. Kun pull‑request suljetaan tai yhdistetään, automaatio poistaa haaran. Koska haara alkaa tuotannosta, skeemamigraatio voidaan toteuttaa ja testata ennen kuin muutos saavuttaa tuotannon. Esimerkki ottaa esikatselut käyttöön Databricks Apps -palvelussa, vaikka artikkeli toteaa, että käsite pätee myös muihin hosting‑alustoihin, kuten Vercel, Netlify ja Cloudflare.

Ympäristöissä artikkeli huomauttaa, että yleinen Lakebase‑asetus käyttää yhtä Databricks‑työtilaa per ympäristö, kuten kehitys, testaus ja tuotanto, ja että tiimit haarautuvat yleensä siemen‑tietokannasta eikä tuotantotietokannasta sensitiivisen datan, kuten henkilötietojen, paljastumisen välttämiseksi. Ohjeistus käyttää yhtä työtilaa yksinkertaisuuden vuoksi, vaikka samat periaatteet pätevät monityötila‑asetuksiin.

Vian toistaminen ja migraatiotestaus

Per-agent- ja per-pull-request -silmukoiden lisäksi artikkeli kuvaa haarautumistyönkulkuja, joita ei ole toteutettu esimerkkivarastossa. Kehittäjä voi luoda eristetyn haaran tuotannosta tiettynä ajankohtana, tyypillisesti juuri ennen kuin virhe ilmeni, toistaa ja tutkia ongelmaa todellisten tietojen avulla, ja poistaa haara käytöstä, kun korjaus on vahvistettu. Tiimit voivat myös luoda haaran ennen tuotantoon käyttöönottoa, soveltaa skeeman migraatiota, suorittaa testejä ja varmistaa, että sovellus käyttäytyy edelleen odotetusti ennen muutoksen edistämistä. Nämä työnkulut antavat kehittäjille mahdollisuuden työskennellä tuotantomaisten tai tuotannosta johdettujen tietojen parissa, esimerkiksi käyttämällä Unity Catalog -maskausta, ilman että elävää tietokantaa asetetaan riskialttiiksi, artikkelin mukaan.

Artikkeli linkittää esimerkkivarastoon GitHubissa, databricks/tmm‑varaston Lakebase-Agentic-CI‑hakemistossa, joka sisältää GitHub Actions -työnkulkuesimerkkejä, jotka toteuttavat mallin. Siinä todetaan, että yhdessä nämä mallit muodostavat sen, mitä se kutsuu Lakebase development loop -kehityssilmukaksi: haara per agent, haara per pull request ja eristetyt haarat tuotannon validointiin.