Lakebase adds one-second, zero-storage copy-on-write branches for terabyte databases

Lakebase has introduced copy-on-write database branching that can create a branch of a terabyte — scale production database in about one second. Branch creation is O(1) and initially consumes no additional storage, allowing teams to spawn isolated, production — shaped branches instantly — a change that makes Practice #4 of Evolutionary Database Design (“everybody gets their own database instance”) operational rather than merely aspirational. This removes a key bottleneck for teams that previously avoided frequent clones due to time and storage costs.

The branching implementation relies on copy-on-write semantics: new branches reference existing data rather than duplicating it at creation time, and only diverge when writes occur. That design keeps branch — creation time constant relative to database size and avoids upfront storage costs; per-branch operations remain proportional to the changes made, not the size of the source dataset.

The announcement frames the capability against two decades of database practice. The patterns and refactorings in Evolutionary Database Design have been known for about 20 years, and Continuous Delivery made migrations a first — class concern in 2010 (chapter 12). What those methodologies did not solve was reliable, isolated pipeline targets; teams compensated with mock objects, shared staging environments, in-memory substitutes, and DBA ticket queues.

In practical terms, instant copy-on-write branches let developers experiment and run migration — backed changes against isolated datasets shaped like production without costly clones or long waits. That preserves production data semantics for testing while enabling feature work and refactorings to proceed in parallel, reducing the friction of validating schema and behavior changes against realistic data. For database administrators, the role is expected to shift from gatekeeper of scarce clone resources to steward of automated, team-scale governance and policy. With branching available on demand, DBAs can focus on access controls, branch lifecycle policies, and auditability rather than provisioning and tracking manual clones.

The blog illustrates the workflow with a developer example: Jen implements a refactor that splits an inventory_code into location_code, batch_number, and serial_number. She must add columns, preserve existing production semantics, and add tests that prove the new fields are stored and displayed correctly. With copy-on-write branching, Jen can perform and validate those schema changes on a per-feature branch that initially costs no additional storage and mirrors production data semantics.

This post is the first in a series that will explore how removing the branching constraint changes practice without altering underlying methodology. Subsequent entries will cover Jen’s day-to-day flow (Part 1), a new playbook for feature and migration work (Part 2), and team-and governance — level effects (Part 3). The item was published on 2026 — 05-29T22:04:37+0000 and focuses on the operational and governance implications builders should consider.