Databricks Menjelaskan Branching Lakebase untuk Agen Pengkodean Paralel

Databricks pada 8 Oktober 2026, menerbitkan sebuah posting blog yang merinci alur kerja pengembangan di mana setiap agen pengkodean paralel dan setiap pull request dijalankan pada basis data Postgres yang terisolasi dan sementara, yang dibuat melalui branching copy-on-write yang terintegrasi dalam layanan basis data Lakebase miliknya.

Dalam posting tersebut, Databricks menggambarkan basis data sebagai bagian yang sering terabaikan dalam alur kerja pengembangan pada saat agen pengkodean mengambil porsi yang semakin besar dari pekerjaan pengembangan dan menjalankan banyak agen secara paralel menjadi norma. Dengan lingkungan bersama tradisional, seperti satu basis data pengembangan atau staging, agen yang bersamaan dapat berbenturan pada perubahan skema, saling mengganggu, atau beralih ke mock yang tidak mencerminkan data dunia nyata. Ini sudah menjadi titik sakit bagi pengembang, kata posting tersebut, namun agen memperburuknya karena mereka bergerak lebih cepat, beroperasi secara paralel, dan membutuhkan lingkungan aman yang menghindari risiko data produksi atau paparan data sensitif.

Mekanika Branching

Databricks mengatakan bahwa branching Lakebase memungkinkan pengguna membuat cabang seluruh basis data dalam kurang dari satu detik, terlepas dari ukurannya. Cabang bergantung pada penyimpanan copy-on-write: sebuah cabang baru mewarisi skema dan data induknya sambil berbagi penyimpanan dasar, hanya mengkonsumsi penyimpanan tambahan saat menyimpang. Menurut dokumentasi branching Lakebase milik Databricks, setiap proyek dibuat dengan cabang default bernama production, dan setiap cabang kecuali cabang akar memiliki induk. Perubahan pada cabang anak tidak pernah memengaruhi induknya, dan isolasi tersebut meluas ke status peran Postgres: peran dan basis data yang dibuat, GRANTs dan REVOKEs yang diterapkan, serta atribut peran yang diubah pada satu cabang tidak berpengaruh pada cabang lain.

Setiap cabang memiliki komputasi sendiri, skala turun menjadi nol saat tidak aktif, dan hanya dikenakan biaya untuk jam komputasi aktif, menurut dokumentasi. Penagihan penyimpanan tergantung pada apakah sebuah cabang kedaluwarsa: cabang yang kedaluwarsa hanya dikenakan biaya untuk data yang berubah di dalamnya, sementara cabang permanen tanpa kedaluwarsa dikenakan biaya untuk ukuran data lengkapnya, seperti basis data independen. Reset cabang, yang menyegarkan cabang anak dari induknya, berfungsi hanya satu arah, dari induk ke anak. Pemulihan pada titik waktu menciptakan cabang akar baru dari data historis dalam jendela pemulihan sambil membiarkan cabang asli tetap tidak berubah dan beroperasi.

Pada halaman produknya, Databricks menjelaskan Lakebase sebagai layanan Postgres serverless yang sepenuhnya dikelola, yang menjalankan mesin Postgres sumber terbuka alih-alih fork.

Satu Cabang per Agen

Alur kerja dalam posting tersebut memadukan worktree Git dengan cabang Lakebase. Sebuah worktree memberikan setiap agen direktori masing-masing dengan cabang yang sudah di-checkout, menghilangkan konflik pada tingkat file antar agen, dan hook pasca-checkout kemudian secara otomatis membuat cabang basis data untuk setiap worktree baru. Dalam contoh, yang dibangun dengan Claude Code, sebuah agen menjalankan claude -worktree feature-123, Git membuat worktree, hook dijalankan, dan agen berakhir dengan direktori kode miliknya sendiri serta basis data yang sepenuhnya terisolasi. Berkas instruksi repositori seperti AGENTS.md atau CLAUDE.md mengarahkan perilaku agen, dan ketika agen selesai ia membuka pull request, setelah itu baik worktree maupun cabang basis data dapat dihentikan.

Salah satu perbedaan dari Git, kata posting tersebut, adalah bahwa cabang Lakebase tidak digabungkan kembali ke cabang utama, karena induk dan anak dapat berubah secara independen dan menyelaraskan data mereka dapat dengan cepat menjadi tidak praktis. Sebagai gantinya, perubahan skema dilacak dalam kode bersama logika aplikasi dan dipromosikan ke cabang induk melalui migrasi, menggunakan alat seperti Drizzle, Flyway, Liquibase, atau Alembic. Contoh tersebut menggunakan Drizzle: ketika perubahan skema diperlukan, agen menambahkan migrasi yang bersesuaian ke basis kode, dan otomatisasi penyebaran menerapkannya saat menyebarkan aplikasi preview dan lagi ketika perubahan digabungkan ke main.

Satu Cabang per Pull Request

Untuk integrasi berkelanjutan, posting tersebut menjabarkan alur kerja GitHub Actions di mana membuka pull request terhadap main memicu Lakebase CLI untuk membuat cabang sementara, yang dinamai sesuai pull request, sebagai anak dari cabang production, dan cabang tersebut menjadi lingkungan basis data pull request. Alat migrasi dijalankan pada cabang baru, aplikasi preview disebarkan dan diarahkan ke string koneksi cabang, dan diff skema dihasilkan serta diposting sebagai komentar pull request yang menunjukkan secara tepat tabel, kolom, atau indeks mana yang berubah. Ketika pull request ditutup atau digabungkan, otomatisasi menghapus cabang tersebut. Karena cabang dimulai dari production, migrasi skema dapat diterapkan dan diuji sebelum perubahan mencapai production. Contoh tersebut menyebarkan preview pada Databricks Apps, meskipun posting menyatakan konsep ini berlaku untuk platform hosting lain seperti Vercel, Netlify, dan Cloudflare.

Pada lingkungan, posting tersebut mencatat bahwa konfigurasi Lakebase yang umum menggunakan satu workspace Databricks per lingkungan, seperti development, staging, dan production, dan tim biasanya membuat cabang dari basis data yang sudah di-seed alih-alih basis data production untuk menghindari paparan data sensitif seperti PII. Panduan ini menggunakan satu workspace untuk kesederhanaan sambil mencatat bahwa konsep yang sama berlaku untuk konfigurasi multi-workspace.

Reproduksi Bug dan Pengujian Migrasi

Selain loop per‑agen dan per‑pull‑request, postingan ini menjelaskan alur kerja branching yang belum diimplementasikan dalam repositori contoh. Seorang pengembang dapat membuat cabang terisolasi dari produksi pada titik waktu tertentu, biasanya tepat sebelum munculnya bug, mereproduksi dan menyelidiki masalah menggunakan data nyata, serta mengarsipkan cabang tersebut setelah perbaikan tervalidasi. Tim juga dapat membuat cabang sebelum melakukan deployment ke produksi, menerapkan migrasi skema, menjalankan tes, dan memverifikasi bahwa aplikasi tetap berperilaku seperti yang diharapkan sebelum mempromosikan perubahan. Alur kerja ini memungkinkan pengembang bekerja dengan data yang mirip produksi atau berasal dari produksi, misalnya menggunakan masking Unity Catalog, tanpa menempatkan basis data live dalam risiko, demikian disebutkan dalam postingan.

Postingan tersebut menautkan ke repositori contoh di GitHub, dalam direktori Lakebase-Agentic-CI pada repositori databricks/tmm, yang berisi contoh alur kerja GitHub Actions yang menerapkan pola tersebut. Ia menyimpulkan bahwa bersama‑sama pola‑pola ini membentuk apa yang disebutnya sebagai loop pengembangan Lakebase: satu cabang per agen, satu cabang per pull request, dan cabang terisolasi untuk validasi produksi.