Databricks on October 8, 2026, printed a weblog submit detailing a growth workflow through which each parallel coding agent and each pull request runs in opposition to its personal remoted, ephemeral Postgres database, created by the copy-on-write branching constructed into its Lakebase database service.
Within the submit, Databricks describes the database as an often-overlooked a part of the event workflow at a time when coding brokers are taking up a rising share of growth work and operating a number of brokers in parallel is turning into the norm. With conventional shared environments, corresponding to a single growth or staging database, concurrent brokers can battle on schema modifications, intrude with each other, or fall again on mocks that don’t mirror real-world knowledge. These had been already ache factors for builders, the submit states, however brokers exacerbate them as a result of they transfer sooner, function in parallel, and wish a secure surroundings that avoids placing manufacturing knowledge in danger or exposing delicate knowledge.
Branching Mechanics
Databricks says Lakebase branching lets a person department a complete database in below a second, no matter its measurement. Branches depend on copy-on-write storage: a brand new department inherits its dad or mum’s schema and knowledge whereas sharing the underlying storage, consuming extra storage solely because it diverges. Based on Databricks’ Lakebase branching documentation, every undertaking is created with a default department named manufacturing, and each department besides the foundation department has a dad or mum. Modifications in a toddler department by no means have an effect on its dad or mum, and the isolation extends to Postgres function state: roles and databases created, GRANTs and REVOKEs utilized, and function attributes modified on one department don’t have any impact on different branches.
Every department has its personal compute, scales to zero when idle, and is billed just for energetic compute hours, the documentation states. Storage billing relies on whether or not a department expires: an expiring department is billed just for the info modified on it, whereas a everlasting department with no expiration is billed for its full knowledge measurement, like an impartial database. A department reset, which refreshes a toddler department from its dad or mum, works in a single path solely, dad or mum to baby. Level-in-time restoration creates a brand new root department from historic knowledge inside the restore window whereas leaving the unique department unchanged and operational.
On its product web page, Databricks describes Lakebase as a totally managed, serverless Postgres service that runs the open-source Postgres engine fairly than a fork.
A Department Per Agent
The workflow within the submit pairs Git worktrees with Lakebase branches. A worktree offers every agent its personal listing with its personal department checked out, eradicating file-level conflicts between brokers, and a post-checkout hook then routinely creates a database department for every new worktree. Within the instance, constructed with Claude Code, an agent runs claude -worktree feature-123, Git creates the worktree, the hook fires, and the agent finally ends up with its personal code listing and its personal absolutely remoted database. Repository instruction recordsdata corresponding to AGENTS.md or CLAUDE.md information agent conduct, and when the agent finishes it opens a pull request, after which each the worktree and the database department may be retired.
One distinction from Git, the submit notes, is that Lakebase branches should not merged again into the principle department, as a result of dad or mum and baby can each change independently and reconciling their knowledge can shortly grow to be impractical. As a substitute, schema modifications are tracked in code alongside software logic and promoted to the dad or mum department by migrations, utilizing instruments corresponding to Drizzle, Flyway, Liquibase, or Alembic. The instance makes use of Drizzle: when a schema change is required, the agent provides the corresponding migration to the codebase, and the deployment automation applies it when deploying the preview software and once more when the change merges into principal.
A Department Per Pull Request
For steady integration, the submit lays out a GitHub Actions workflow through which opening a pull request in opposition to principal triggers the Lakebase CLI to create an ephemeral department, named after the pull request, as a toddler of the manufacturing department, and that department turns into the pull request’s database surroundings. The migration device runs in opposition to the brand new department, a preview software is deployed and pointed on the department’s connection string, and a schema diff is generated and posted as a pull-request remark displaying precisely which tables, columns, or indexes modified. When the pull request is closed or merged, the automation deletes the department. As a result of the department begins from manufacturing, the schema migration may be utilized and examined earlier than the change reaches manufacturing. The instance deploys previews on Databricks Apps, although the submit states the idea applies to different internet hosting platforms corresponding to Vercel, Netlify, and Cloudflare.
On environments, the submit notes {that a} widespread Lakebase setup makes use of one Databricks workspace per surroundings, corresponding to growth, staging, and manufacturing, and that groups generally department from a seeded database fairly than the manufacturing database to keep away from exposing delicate knowledge corresponding to PII. The walkthrough makes use of a single workspace for simplicity whereas noting the identical ideas apply to multi-workspace setups.
Bug Copy and Migration Testing
Past the per-agent and per-pull-request loops, the submit describes branching workflows that aren’t carried out within the instance repository. A developer can create an remoted department from manufacturing at a particular time limit, usually simply earlier than a bug appeared, reproduce and examine the difficulty in opposition to actual knowledge, and retire the department as soon as a repair is validated. Groups can even create a department earlier than deploying to manufacturing, apply a schema migration, run exams, and confirm the appliance nonetheless behaves as anticipated earlier than selling the change. These workflows let builders work with production-like or production-derived knowledge, utilizing Unity Catalog masking for instance, with out placing the dwell database in danger, the submit states.
The submit hyperlinks to an instance repository on GitHub, within the Lakebase-Agentic-CI listing of the databricks/tmm repository, which accommodates GitHub Actions workflow examples implementing the sample. It concludes that collectively these patterns type what it calls the Lakebase growth loop: a department per agent, a department per pull request, and remoted branches for manufacturing validation.
