Databricks розкриває розгалуження Lakebase для паралельних кодових агентів

Databricks 8 жовтня 2026 року опублікував пост у блозі, у якому докладно описано робочий процес розробки, в якому кожен паралельний кодовий агент і кожен pull request працює зі своєю ізольованою, короткоживучою базою даних Postgres, створеною за допомогою розгалуження copy‑on‑write, вбудованого в його Lakebase сервіс бази даних.

У цьому пості Databricks описує базу даних як часто недооцінений елемент робочого процесу розробки у час, коли кодові агенти беруть на себе все більшу частку розробницької роботи, а запуск кількох агентів паралельно стає нормою. У традиційних спільних середовищах, таких як єдина база даних для розробки або тестування, одночасні агенти можуть конфліктувати під час змін схеми, заважати один одному або покладатися на мок‑об’єкти, які не відображають реальні дані. Ці проблеми вже були болючими для розробників, зазначає пост, але агенти посилюють їх, бо працюють швидше, діють паралельно та потребують безпечного середовища, яке не ставить під загрозу дані продакшну та не розкриває конфіденційні дані.

Механіка розгалуження

Databricks стверджує, що розгалуження Lakebase дозволяє користувачеві створювати гілку всієї бази даних за менше ніж секунду, незалежно від її розміру. Гілки базуються на сховищі copy‑on‑write: нова гілка успадковує схему та дані батька, одночасно ділячись підлеглим сховищем, споживаючи додаткове сховище лише при розходженні. За даними Документація з розгалуження Lakebase від Databricks, кожен проєкт створюється з гілкою за замовчуванням під назвою production, і кожна гілка, окрім кореневої, має батька. Зміни в дочірній гілці ніколи не впливають на її батька, і ізоляція поширюється на стан ролей Postgres: створені ролі та бази даних, застосовані GRANT та REVOKE, а також змінені атрибути ролей у одній гілці не мають впливу на інші гілки.

Кожна гілка має власні обчислювальні ресурси, масштабується до нуля під час бездіяльності і оплачується лише за активні години обчислень, зазначає документація. Оплата сховища залежить від того, чи закінчується термін дії гілки: гілка з закінченням терміну оплачується лише за змінені дані, тоді як постійна гілка без закінчення терміну оплачується за весь обсяг даних, подібно до незалежної бази даних. Скидання гілки, яке оновлює дочірню гілку з батьківської, працює лише в одному напрямку — від батька до дитини. Відновлення у певний момент часу створює нову кореневу гілку з історичних даних у межах вікна відновлення, залишаючи оригінальну гілку незмінною та працездатною.

На сторінці продукту Databricks описує Lakebase як повністю керований, безсерверний сервіс Postgres, який працює на відкритому рушії Postgres, а не на його форку.

Одна гілка на агента

У цьому пості робочий процес поєднує Git worktrees з гілками Lakebase. Worktree надає кожному агенту власний каталог зі своєю гілкою, що виключає конфлікти на рівні файлів між агентами, а post‑checkout хук автоматично створює гілку бази даних для кожного нового worktree. У прикладі, створеному за допомогою Claude Code, агент запускає claude -worktree feature-123, Git створює worktree, хук спрацьовує, і агент отримує власний каталог коду та повністю ізольовану базу даних. Файли інструкцій репозиторію, такі як AGENTS.md або CLAUDE.md, керують поведінкою агента, і коли агент завершує роботу, він відкриває pull‑request, після чого і worktree, і гілка бази даних можуть бути завершені.

Одне відмінність від Git, зазначає пост, полягає в тому, що гілки Lakebase не зливаються назад у головну гілку, оскільки батько і дитина можуть змінюватися незалежно, і узгодження їхніх даних швидко стає непрактичним. Натомість зміни схеми відстежуються в коді разом з логікою застосунку та просуваються до батьківської гілки за допомогою міграцій, використовуючи інструменти такі як Drizzle, Flyway, Liquibase або Alembic. У прикладі використовується Drizzle: коли потрібна зміна схеми, агент додає відповідну міграцію до кодової бази, а автоматизація розгортання застосовує її під час розгортання попереднього перегляду застосунку і знову, коли зміна зливається у main.

Одна гілка на pull‑request

Для безперервної інтеграції пост описує workflow GitHub Actions, у якому відкриття pull‑request проти main ініціює Lakebase CLI створити короткоживучу гілку, названу за назвою pull‑request, як дочірню до гілки production, і ця гілка стає середовищем бази даних для pull‑request. Інструмент міграції працює проти нової гілки, розгортається попередній перегляд застосунку, який підключається до рядка підключення гілки, і генерується diff схеми, який публікується як коментар до pull‑request, показуючи точно, які таблиці, стовпці або індекси змінилися. Коли pull‑request закривається або зливається, автоматизація видаляє гілку. Оскільки гілка створюється з production, міграція схеми може бути застосована та протестована до того, як зміна потрапить у production. У прикладі попередні перегляди розгортаються на Databricks Apps, хоча пост зазначає, що концепція застосовується до інших хостингових платформ, таких як Vercel, Netlify та Cloudflare.

Щодо середовищ, пост зазначає, що типова конфігурація Lakebase використовує один робочий простір Databricks на кожне середовище, наприклад development, staging та production, і що команди зазвичай створюють гілки з підготовленої бази даних, а не з production, щоб уникнути розкриття конфіденційних даних, таких як PII. У демонстрації використовується один робочий простір для спрощення, при цьому зазначається, що ті ж концепції застосовуються до конфігурацій з кількома робочими просторами.

Відтворення помилок та тестування міграцій

Поза циклами per-agent та per-pull-request, у дописі описуються робочі процеси гілкування, які не реалізовані у прикладному репозиторії. Розробник може створити ізольовану гілку з продакшну у певний момент часу, зазвичай безпосередньо перед появою помилки, відтворити та дослідити проблему на реальних даних і закрити гілку після підтвердження виправлення. Команди також можуть створити гілку перед розгортанням у продакшн, застосувати міграцію схеми, запустити тести та переконатися, що застосунок продовжує працювати належним чином, перш ніж просунути зміни. Ці робочі процеси дозволяють розробникам працювати з даними, схожими на продакшн або отриманими з продакшну, використовуючи, наприклад, маскування Unity Catalog, без ризику для живої бази даних, зазначає допис.

У дописі є посилання на прикладний репозиторій на GitHub, у каталозі Lakebase-Agentic-CI репозиторію databricks/tmm, який містить приклади робочих процесів GitHub Actions, що реалізують цей шаблон. Автор робить висновок, що разом ці шаблони утворюють те, що він називає циклом розробки Lakebase: гілка на агента, гілка на pull‑request та ізольовані гілки для валідації продакшну.