Databricks, Paralel Kodlama Ajanları için Lakebase Dallanmasını Detaylandırıyor

Databricks, 8 Ekim 2026 tarihinde, bir blog gönderisi yayınladı ve her paralel kodlama ajanının ve her çekme isteğinin kendi izole, geçici Postgres veritabanı üzerinde çalıştığı bir geliştirme iş akışını detaylandırdı; bu veritabanı, Lakebase veritabanı hizmetine yerleşik copy-on-write dallanma özelliğiyle oluşturulmaktadır.

Yazıda, Databricks veritabanını, kodlama ajanlarının geliştirme işinin giderek daha büyük bir kısmını üstlendiği ve birden fazla ajanın paralel çalışmasının norm haline geldiği bir dönemde, geliştirme iş akışının sıkça göz ardı edilen bir parçası olarak tanımlıyor. Geleneksel paylaşımlı ortamlar, örneğin tek bir geliştirme veya hazırlık veritabanı, eşzamanlı ajanların şema değişiklikleri üzerinde çakışmasına, birbirlerine müdahale etmesine ya da gerçek dünyadaki verileri yansıtmayan taklitlere başvurmalarına neden olabilir. Bunlar zaten geliştiriciler için sorunlardı, yazı belirtiyor, ancak ajanlar daha hızlı hareket ettikleri, paralel çalıştıkları ve üretim verilerini riske atmaktan ya da hassas verileri ortaya çıkarmaktan kaçınan güvenli bir ortama ihtiyaç duydukları için bu sorunları daha da şiddetlendiriyor.

Dallanma Mekaniği

Databricks, Lakebase dallanmasının bir kullanıcının bir bütün veritabanını bir saniyeden kısa bir sürede, boyutu ne olursa olsun, dallanmasına izin verdiğini söylüyor. Dallar, copy-on-write depolamaya dayanır: yeni bir dal, üst dalın şemasını ve verilerini devralırken temel depolamayı paylaşır ve yalnızca ayrıştıkça ek depolama tüketir. Databricks’ın Lakebase dallanma belgelerine göre, her proje, production adlı varsayılan bir dal ile oluşturulur ve kök dal dışındaki her dalın bir üst dalı vardır. Çocuk dalda yapılan değişiklikler asla üst dalı etkilemez ve izolasyon Postgres rol durumuna da uzanır: bir dalda oluşturulan roller ve veritabanları, verilen GRANT ve REVOKE’lar ve rol özniteliklerinde yapılan değişiklikler diğer dalları etkilemez.

Her dalın kendi işlem gücü vardır, boşta iken sıfıra ölçeklenir ve yalnızca aktif işlem saatleri için faturalandırılır, belge bunu belirtmektedir. Depolama faturalandırması, bir dalın süresi dolup dolmadığına bağlıdır: süresi dolan bir dal, yalnızca üzerinde değiştirilen veri için faturalandırılırken, süresi olmayan kalıcı bir dal, bağımsız bir veritabanı gibi tam veri boyutu için faturalandırılır. Bir dal sıfırlama, bir çocuk dalı üst dalından yenileyen bir işlemdir ve yalnızca üstten çocuğa doğru çalışır. Zaman noktasında geri kurtarma, geri yükleme penceresi içindeki tarihsel verilerden yeni bir kök dal oluşturur ve orijinal dalı değişmeden ve çalışır durumda bırakır.

ürün sayfasında, Databricks, Lakebase’i açık kaynak Postgres motorunu bir çatallama yerine çalıştıran, tam yönetilen, sunucusuz bir Postgres hizmeti olarak tanımlıyor.

Ajan Başına Bir Dal

Yazıdaki iş akışı, Git worktree’lerini Lakebase dallarıyla eşleştiriyor. Bir worktree, her ajana kendi dizinini ve kendi checkout edilmiş dalını sağlar; bu, ajanlar arasındaki dosya düzeyindeki çakışmaları ortadan kaldırır ve bir post-checkout kancası, her yeni worktree için otomatik olarak bir veritabanı dalı oluşturur. Örnekte, Claude Code ile oluşturulmuş, bir ajan çalıştırır claude -worktree feature-123, Git worktree’i oluşturur, kanca tetiklenir ve ajan kendi kod dizini ve tamamen izole bir veritabanına sahip olur. AGENTS.md veya CLAUDE.md gibi depo talimat dosyaları ajan davranışını yönlendirir ve ajan işini bitirdiğinde bir çekme isteği (pull request) açar; ardından worktree ve veritabanı dalı her ikisi de kaldırılabilir.

Yazının belirttiği bir fark, Git’ten farklı olarak, Lakebase dallarının ana dala geri birleştirilmemesidir; çünkü üst ve alt dallar bağımsız olarak değişebilir ve verilerinin uzlaştırılması hızla uygulanamaz hale gelebilir. Bunun yerine, şema değişiklikleri, uygulama mantığıyla birlikte kodda izlenir ve Drizzle, Flyway, Liquibase veya Alembic gibi araçlar kullanılarak göçler (migrations) aracılığıyla üst dala yükseltilir. Örnek Drizzle’ı kullanır: bir şema değişikliği gerektiğinde, ajan ilgili göçü kod tabanına ekler ve dağıtım otomasyonu, ön izleme uygulamasını dağıtırken ve değişiklik ana dala birleştirildiğinde bunu uygular.

Çekme İsteği Başına Bir Dal

Sürekli entegrasyon için, yazı bir GitHub Actions iş akışı sunar; bu iş akışında, main’e bir çekme isteği açılması, Lakebase CLI’yi, çekme isteği adıyla adlandırılmış geçici bir dal oluşturmak için tetikler; bu dal, production dalının bir çocuğu olur ve çekme isteğinin veritabanı ortamı haline gelir. Göç aracı yeni dalda çalışır, bir ön izleme uygulaması dağıtılır ve dalın bağlantı dizesine yönlendirilir; ayrıca bir şema farkı (diff) oluşturulur ve hangi tablo, sütun veya indekslerin değiştiğini gösteren bir çekme isteği yorumu olarak gönderilir. Çekme isteği kapatıldığında veya birleştirildiğinde, otomasyon dalı siler. Dal production’dan başladığı için, şema göçü, değişiklik production’a ulaşmadan önce uygulanabilir ve test edilebilir. Örnek, Databricks Apps üzerinde ön izlemeler dağıtır; ancak yazı, kavramın Vercel, Netlify ve Cloudflare gibi diğer barındırma platformlarına da uygulanabileceğini belirtir.

Ortamlar hakkında, yazı yaygın bir Lakebase kurulumunun her ortam için bir Databricks çalışma alanı (workspace) kullandığını, örneğin geliştirme, hazırlık ve üretim, ve ekiplerin genellikle üretim veritabanı yerine önceden doldurulmuş (seeded) bir veritabanından dallandığını, böylece Kişisel Tanımlanabilir Bilgi (PII) gibi hassas verilerin ortaya çıkmasını önlediğini belirtir. Kılavuz, basitlik açısından tek bir çalışma alanı kullanırken aynı kavramların çoklu çalışma alanı kurulumlarına da uygulandığını vurgular.

Hata Çoğaltma ve Göç Testi

Her ajan ve her çekme isteği döngülerinin ötesinde, gönderi örnek deposunda uygulanmayan dallanma iş akışlarını açıklıyor. Bir geliştirici, üretimden belirli bir zamanda, genellikle bir hatanın ortaya çıkmasından hemen önce, izole bir dal oluşturabilir, gerçek verilerle sorunu yeniden üretebilir ve inceleyebilir ve bir düzeltme doğrulandıktan sonra dalı kapatabilir. Takımlar ayrıca üretime dağıtmadan önce bir dal oluşturabilir, bir şema geçişi uygulayabilir, testleri çalıştırabilir ve değişikliği yükseltmeden önce uygulamanın hâlâ beklendiği gibi davrandığını doğrulayabilir. Bu iş akışları, geliştiricilerin Unity Catalog maskeleme gibi yöntemleri kullanarak üretim benzeri veya üretimden türetilmiş verilerle çalışmasına olanak tanır, canlı veritabanını riske atmadan, gönderi belirtiyor.

Gönderi, GitHub üzerindeki örnek depoya, databricks/tmm deposunun Lakebase-Agentic-CI dizininde, örüntüyü uygulayan GitHub Actions iş akışı örneklerini içeren bir bağlantı verir. Birlikte bu örüntülerin, gönderinin “Lakebase geliştirme döngüsü” olarak adlandırdığı şeyi oluşturduğunu sonucuna varır: her ajan için bir dal, her çekme isteği için bir dal ve üretim doğrulaması için izole dallar.