Databricks opisuje rozgałęzianie Lakebase dla równoległych agentów kodujących

Databricks 8 października 2026 r. opublikował post na blogu opisujący przepływ pracy deweloperskiej, w którym każdy równoległy agent kodujący i każde żądanie scalenia działa na własnej, odizolowanej, efemerycznej bazie danych Postgres, utworzonej za pomocą rozgałęziania copy‑on‑write wbudowanego w jego usługę bazodanową Lakebase.

W poście Databricks opisuje bazę danych jako często pomijaną część przepływu pracy deweloperskiej w czasie, gdy agenci kodujący przejmują rosnącą część prac rozwojowych, a uruchamianie wielu agentów równolegle staje się normą. W tradycyjnych współdzielonych środowiskach, takich jak pojedyncza baza danych deweloperska lub testowa, równoczesni agenci mogą kolidować przy zmianach schematu, wzajemnie się zakłócać lub korzystać z atrap, które nie odzwierciedlają rzeczywistych danych. Były to już problemy dla programistów, jak podaje post, ale agenci nasilają je, ponieważ działają szybciej, pracują równolegle i potrzebują bezpiecznego środowiska, które nie naraża danych produkcyjnych na ryzyko ani nie ujawnia wrażliwych danych.

Mechanika rozgałęziania

Databricks twierdzi, że rozgałęzianie Lakebase pozwala użytkownikowi rozgałęzić całą bazę danych w mniej niż sekundę, niezależnie od jej rozmiaru. Rozgałęzienia opierają się na pamięci copy‑on‑write: nowe rozgałęzienie dziedziczy schemat i dane swojego rodzica, jednocześnie współdzieląc podstawową pamięć, zużywając dodatkową pojemność tylko w miarę odchodzenia od niego. Według dokumentacji rozgałęziania Lakebase firmy Databricks, każdy projekt tworzony jest z domyślnym rozgałęzieniem o nazwie production, a każde rozgałęzienie oprócz głównego ma rodzica. Zmiany w rozgałęzieniu potomnym nigdy nie wpływają na jego rodzica, a izolacja obejmuje także stan ról Postgres: role i bazy danych utworzone, przyznane uprawnienia GRANT i REVOKE oraz zmodyfikowane atrybuty roli w jednym rozgałęzieniu nie mają wpływu na inne rozgałęzienia.

Każde rozgałęzienie ma własną moc obliczeniową, skaluje się do zera w stanie bezczynności i jest rozliczane wyłącznie za aktywne godziny obliczeniowe, jak podaje dokumentacja. Rozliczanie pamięci zależy od tego, czy rozgałęzienie wygasa: rozgałęzienie wygasające jest rozliczane tylko za zmienione dane, natomiast stałe rozgałęzienie bez wygaśnięcia jest rozliczane za pełny rozmiar danych, jak niezależna baza danych. Reset rozgałęzienia, który odświeża rozgałęzienie potomne z rodzica, działa w jednym kierunku – od rodzica do potomka. Odzyskiwanie punktowe tworzy nowe rozgałęzienie główne z danych historycznych w oknie przywracania, pozostawiając pierwotne rozgałęzienie niezmienione i operacyjne.

Na jej stronie produktowej Databricks opisuje Lakebase jako w pełni zarządzaną, bezserwerową usługę Postgres, która uruchamia otwarto‑źródłowy silnik Postgres, a nie jego fork.

Jedno rozgałęzienie na agenta

Przepływ pracy opisany w poście łączy worktree Git z rozgałęzieniami Lakebase. Worktree zapewnia każdemu agentowi własny katalog z wyewidencjonowanym własnym rozgałęzieniem, eliminując konflikty na poziomie plików między agentami, a hak post‑checkout automatycznie tworzy rozgałęzienie bazy danych dla każdego nowego worktree. W przykładzie, zbudowanym przy użyciu Claude Code, agent uruchamia claude -worktree feature-123, Git tworzy worktree, hak się uruchamia, a agent otrzymuje własny katalog z kodem oraz własną w pełni odizolowaną bazę danych. Pliki instrukcji repozytorium, takie jak AGENTS.md lub CLAUDE.md, kierują zachowaniem agenta, a po zakończeniu agent otwiera żądanie scalenia, po czym zarówno worktree, jak i rozgałęzienie bazy danych mogą zostać wycofane.

Jedną różnicą w stosunku do Git, jak zauważa post, jest to, że rozgałęzienia Lakebase nie są scalane z głównym rozgałęzieniem, ponieważ rodzic i potomek mogą zmieniać się niezależnie, a uzgadnianie ich danych może szybko stać się niepraktyczne. Zamiast tego zmiany schematu są śledzone w kodzie razem z logiką aplikacji i promowane do rozgałęzienia nadrzędnego poprzez migracje, przy użyciu narzędzi takich jak Drizzle, Flyway, Liquibase czy Alembic. Przykład używa Drizzle: gdy potrzebna jest zmiana schematu, agent dodaje odpowiednią migrację do repozytorium kodu, a automatyzacja wdrożenia stosuje ją przy wdrażaniu aplikacji podglądowej i ponownie, gdy zmiana zostaje scalona z główną gałęzią.

Jedno rozgałęzienie na żądanie scalenia

W ramach ciągłej integracji post opisuje przepływ pracy GitHub Actions, w którym otwarcie żądania scalenia w stosunku do main wyzwala Lakebase CLI do utworzenia efemerycznego rozgałęzienia, nazwanego po żądaniu scalenia, jako potomka rozgałęzienia production, które staje się środowiskiem bazodanowym tego żądania. Narzędzie migracji działa na nowym rozgałęzieniu, wdrażana jest aplikacja podglądowa skierowana na łańcuch połączeniowy rozgałęzienia, a różnica schematu jest generowana i publikowana jako komentarz do żądania scalenia, pokazując dokładnie, które tabele, kolumny lub indeksy uległy zmianie. Gdy żądanie scalenia zostaje zamknięte lub scalone, automatyzacja usuwa rozgałęzienie. Ponieważ rozgałęzienie rozpoczyna się od produkcji, migracja schematu może być zastosowana i przetestowana przed wprowadzeniem zmiany do produkcji. Przykład wdraża podglądy w Databricks Apps, choć post stwierdza, że koncepcja ma zastosowanie do innych platform hostingowych, takich jak Vercel, Netlify i Cloudflare.

W odniesieniu do środowisk post zauważa, że typowa konfiguracja Lakebase wykorzystuje jeden workspace Databricks na środowisko, takie jak development, staging i production, oraz że zespoły zazwyczaj rozgałęziają się z bazy danych seedowanej, a nie z bazy produkcyjnej, aby uniknąć udostępniania wrażliwych danych, takich jak PII. Przewodnik używa jednego workspace dla uproszczenia, jednocześnie podkreślając, że te same koncepcje mają zastosowanie w konfiguracjach wieloworkspace.

Reprodukcja błędów i testowanie migracji

Poza pętlami per-agent i per-pull-request, post opisuje przepływy pracy z gałęziami, które nie zostały zaimplementowane w przykładowym repozytorium. Programista może utworzyć izolowaną gałąź z produkcji w określonym punkcie w czasie, zazwyczaj tuż przed pojawieniem się błędu, odtworzyć i zbadać problem na rzeczywistych danych oraz usunąć gałąź po zweryfikowaniu poprawki. Zespoły mogą również utworzyć gałąź przed wdrożeniem do produkcji, zastosować migrację schematu, uruchomić testy i sprawdzić, czy aplikacja nadal zachowuje się zgodnie z oczekiwaniami przed promowaniem zmiany. Te przepływy pracy pozwalają programistom pracować na danych podobnych do produkcyjnych lub pochodzących z produkcji, używając na przykład maskowania Unity Catalog, bez narażania działającej bazy danych, jak podaje post.

Post odsyła do przykładowego repozytorium na GitHub, w katalogu Lakebase-Agentic-CI repozytorium databricks/tmm, które zawiera przykłady przepływów pracy GitHub Actions implementujące ten wzorzec. Wnioskuje, że razem te wzorce tworzą to, co nazywa pętlą rozwoju Lakebase: gałąź na agenta, gałąź na pull request oraz izolowane gałęzie do walidacji produkcji.