Databricks descrive il branching di Lakebase per agenti di codifica parallela

Databricks l’8 ottobre 2026 ha pubblicato un post sul blog che descrive un flusso di lavoro di sviluppo in cui ogni agente di codifica parallela e ogni pull request vengono eseguiti su un proprio database Postgres isolato ed effimero, creato tramite il branching copy‑on‑write integrato nel suo servizio database Lakebase.

Nel post, Databricks descrive il database come una parte spesso trascurata del flusso di lavoro di sviluppo in un momento in cui gli agenti di codifica stanno assumendo una quota crescente del lavoro di sviluppo e l’esecuzione di più agenti in parallelo sta diventando la norma. Con gli ambienti condivisi tradizionali, come un unico database di sviluppo o di staging, gli agenti concorrenti possono entrare in conflitto su modifiche allo schema, interferire l’uno con l’altro o ricorrere a mock che non riflettono dati reali. Questi erano già punti dolenti per gli sviluppatori, afferma il post, ma gli agenti li aggravano perché si muovono più velocemente, operano in parallelo e necessitano di un ambiente sicuro che eviti di mettere a rischio i dati di produzione o di esporre dati sensibili.

Meccaniche del branching

Databricks afferma che il branching di Lakebase consente a un utente di creare un branch di un intero database in meno di un secondo, indipendentemente dalle sue dimensioni. I branch si basano su storage copy‑on‑write: un nuovo branch eredita lo schema e i dati del genitore condividendo lo storage sottostante, consumando spazio aggiuntivo solo man mano che diverge. Secondo documentazione sul branching di Lakebase di Databricks, ogni progetto viene creato con un branch predefinito chiamato production, e ogni branch tranne quello radice ha un genitore. Le modifiche in un branch figlio non influenzano mai il suo genitore, e l’isolamento si estende allo stato dei ruoli Postgres: ruoli e database creati, GRANT e REVOKE applicati, e attributi di ruolo modificati su un branch non hanno effetto sugli altri branch.

Ogni branch dispone del proprio compute, si scala a zero quando inattivo e viene fatturato solo per le ore di compute attive, secondo la documentazione. La fatturazione dello storage dipende dal fatto che un branch scada o meno: un branch in scadenza viene fatturato solo per i dati modificati su di esso, mentre un branch permanente senza scadenza viene fatturato per l’intera dimensione dei dati, come un database indipendente. Un reset del branch, che aggiorna un branch figlio dal suo genitore, funziona in una sola direzione, dal genitore al figlio. Il recupero puntuale (point‑in‑time recovery) crea un nuovo branch radice dai dati storici entro la finestra di ripristino, lasciando intatto e operativo il branch originale.

Nella la sua pagina prodotto, Databricks descrive Lakebase come un servizio Postgres completamente gestito e serverless che esegue il motore Postgres open‑source anziché un fork.

Un branch per agente

Il flusso di lavoro nel post abbina i worktree di Git ai branch di Lakebase. Un worktree fornisce a ciascun agente la propria directory con il proprio branch checkoutato, eliminando i conflitti a livello di file tra gli agenti, e un hook post‑checkout crea automaticamente un branch di database per ogni nuovo worktree. Nell’esempio, costruito con Claude Code, un agente esegue claude -worktree feature-123, Git crea il worktree, il hook si attiva e l’agente ottiene la propria directory di codice e il proprio database completamente isolato. File di istruzioni del repository come AGENTS.md o CLAUDE.md guidano il comportamento dell’agente e, al termine, l’agente apre una pull request, dopo la quale sia il worktree sia il branch del database possono essere eliminati.

Una differenza rispetto a Git, osserva il post, è che i branch di Lakebase non vengono fusi nuovamente nel branch principale, poiché genitore e figlio possono modificarsi indipendentemente e la riconciliazione dei loro dati può diventare rapidamente impraticabile. Invece, le modifiche allo schema sono tracciate nel codice insieme alla logica dell’applicazione e promosse al branch genitore tramite migrazioni, utilizzando strumenti come Drizzle, Flyway, Liquibase o Alembic. L’esempio utilizza Drizzle: quando è necessaria una modifica allo schema, l’agente aggiunge la migrazione corrispondente al codebase, e l’automazione di distribuzione la applica durante il deployment dell’applicazione preview e nuovamente quando la modifica viene fusa nel main.

Un branch per pull request

Per l’integrazione continua, il post descrive un flusso di lavoro GitHub Actions in cui l’apertura di una pull request contro il branch main attiva il CLI di Lakebase per creare un branch effimero, denominato come la pull request, come figlio del branch production, e quel branch diventa l’ambiente database della pull request. Lo strumento di migrazione viene eseguito sul nuovo branch, viene distribuita un’applicazione preview puntata alla stringa di connessione del branch, e viene generata una diff di schema pubblicata come commento alla pull request che mostra esattamente quali tabelle, colonne o indici sono cambiati. Quando la pull request viene chiusa o fusa, l’automazione elimina il branch. Poiché il branch parte da production, la migrazione di schema può essere applicata e testata prima che la modifica raggiunga la produzione. L’esempio distribuisce preview su Databricks Apps, sebbene il post affermi che il concetto si applichi ad altre piattaforme di hosting come Vercel, Netlify e Cloudflare.

Per gli ambienti, il post osserva che una configurazione comune di Lakebase utilizza un workspace Databricks per ambiente, come sviluppo, staging e produzione, e che i team tipicamente creano branch da un database seedato anziché dal database di produzione per evitare di esporre dati sensibili come i PII. La dimostrazione utilizza un unico workspace per semplicità, notando comunque che gli stessi concetti si applicano a configurazioni multi‑workspace.

Riproduzione di bug e test di migrazione

Oltre ai cicli per agente e per pull request, il post descrive flussi di lavoro di branching non implementati nel repository di esempio. Uno sviluppatore può creare un ramo isolato dalla produzione in un momento specifico, tipicamente appena prima che si manifesti un bug, riprodurre e indagare il problema su dati reali, e chiudere il ramo una volta convalidata la correzione. I team possono anche creare un ramo prima di distribuire in produzione, applicare una migrazione di schema, eseguire i test e verificare che l’applicazione si comporti ancora come previsto prima di promuovere la modifica. Questi flussi di lavoro consentono agli sviluppatori di lavorare con dati simili alla produzione o derivati dalla produzione, utilizzando, ad esempio, il mascheramento di Unity Catalog, senza mettere a rischio il database live, afferma il post.

Il post collega a un repository di esempio su GitHub, nella directory Lakebase-Agentic-CI del repository databricks/tmm, che contiene esempi di workflow GitHub Actions che implementano il modello. Conclude che, insieme, questi modelli costituiscono quello che chiama il ciclo di sviluppo Lakebase: un ramo per agente, un ramo per pull request e rami isolati per la convalida in produzione.