Why this sequence exists
The methodology described in Evolutionary Database Design and operationalized in Refactoring Databases: Evolutionary Database Design has been clear for twenty years. The seven practices, the catalog of 70+ named refactorings, the transition mechanics – all of it documented, peer-reviewed, taught.
That methodology reached CI/CD in 2010 with Steady Supply (Chapter 12: Managing Information). Migrations turned first-class artifacts within the deployment pipeline. The self-discipline of database-changes-as-code reached the broader CI/CD motion. What CD did not clear up was per-pipeline isolation: pipelines may run migrations, however they nonetheless wanted a goal database, and that focus on was shared. Observe #4 – All people will get their very own database occasion – has stayed aspirational on most groups as a result of true per-developer production-shaped databases price time, cash, and DBA cycles. The compensating layer that emerged to work across the hole (mock objects, shared staging environments, in-memory database substitutes, DBA ticket queues) turned foundational methodology by default, not by design.
In 2026, copy-on-write database branching arrives in Databricks Lakebase. A one-second, zero-storage-at-creation department of a terabyte-scale manufacturing database is now an O(1) operation. The constraint that saved Observe #4 aspirational has lifted.
This sequence describes what modifications when the constraint lifts: not the methodology – that holds – however the practices that emerge for the primary time, the team-scale governance that turns into automated, the function evolution for the DBA, and the brand new substrate that brokers share with their human counterparts.
Meet Jen
Jen is the developer character from Evolutionary Database Design. In that essay she applied a database refactoring – splitting an inventory_code subject into location_code, batch_number, and serial_number – as a routine person story, illustrating that DBAs and builders can collaborate, schemas can evolve in small increments, and migrations carry the change ahead safely.
The sequence picks up with Jen twenty years later. The methodology she follows is similar one she adopted in 2003. What’s new is the substrate beneath her workflow: copy-on-write database branching, which makes the practices she has been studying about operationally actual at manufacturing scale. Throughout the three elements of this sequence she is similar Jen at three scopes – her day (Half 1), her new playbook (Half 2), and her group (Half 3).
Half 1: Jen’s story: one function, one database change
To grasp how this works, let’s stroll by way of the journey of how a developer named Jen implements a job that states that the person ought to be capable of see, search and replace the situation, batch and serial variety of a manufacturing in stock.
The next describes the assorted steps Jen has to take to perform this job, whereas describing the steps we’ll attempt to examine how Jen’s workflow modifications when working with conventional databases and utilizing Lakebase that permits database branching at minimal price.
Jen begins engaged on her function job
Jen picks up what appears to be like like an easy function. The product group desires to permit customers to seize location, batch and serial variety of an merchandise throughout stock addition and use it later within the utility stream. From the skin, the change feels small: add a subject to the display, save the worth, present it within the Stock display for an merchandise, and perhaps use it in a downstream resolution later.
For Jen, the appliance change is straightforward to image. She is aware of the place the shape lives. She is aware of which service handles the request. She will see the mannequin object that wants extra attributes. However the second she traces the change throughout, she sees the actual dependency, the database has to alter too.
Some new columns are wanted, current information within the manufacturing setting must be preserved and must be semantically appropriate. The appliance should deal with previous and new information safely and he or she wants so as to add assessments to show that the brand new fields are saved, learn, and displayed accurately. What appeared like a easy function is now a coordinated utility and database change, with the added duty of making certain current manufacturing schema and information is migrated to the brand new schema.
Shared database
Jen creates a code department for the work she about to embark on, and since they’re utilizing a shared database and the remainder of the group is utilizing the identical database for growth, she instantly begins serious about all of the modifications she goes to introduce within the database layer that might have an effect on different customers of the shared database and begins planning on how she will be able to make it protected for others, may she run make the appliance change domestically and be capable of run her unit and integration assessments? Every possibility has prices. She will wait. She will ask the group to coordinate. She will rise up her personal native Postgres in Docker, seed it with a stale pg_dump from per week in the past, and hope the variations do not matter. She will fall again operating an area database in a container or to an in-memory database H2 or SQLite that runs quick however makes use of the flawed dialect, so her assessments move domestically and floor unknown failures on actual Postgres. Can she even take a look at her schema and information migration scripts? This worry of breaking others slows her down and on the identical time doesn’t permit her to experiment with a number of choices of constructing the function.
Since in a shared database, one developer could also be testing a enterprise logic change, one other is debugging a knowledge migration, another person created take a look at information that Jen doesn’t perceive. If Jen applies her schema change to the shared database, she could break another person’s work. If another person modifications the schema whereas she is testing, her outcomes could not be dependable. If she provides take a look at information, it might intrude with one other developer’s assumptions.
Jen can wait till the shared database is free, which protects the group from collisions, but it surely turns a small function right into a scheduling drawback and productiveness loss. She will coordinate manually with the opposite builders: “Are you utilizing dev proper now?” “Can I run a migration?” “Please don’t reset the info for the subsequent hour.” one thing like a baton in a relay race, That works for some time, but it surely doesn’t scale, particularly with a distant or multi timezone group.
Jen thinks of an alternative choice, utilizing an area in-memory database, she is aware of that this setup doesn’t match the state of the database utilized by the remainder of the group, which implies she won’t have the boldness in her answer because the change may go domestically and nonetheless fail later when its meets the actual information and schema in larger environments like staging and manufacturing.
The true drawback Jen is encountering is of slower suggestions she will be able to make the change, however discovering out if the change works, however quick and life like suggestions and with out this suggestions the database change turns into one thing the group treats fastidiously and finally ends up selecting the primary answer that works and by no means experiments or tries a number of options, thus resulting in suboptimal options, decreased productiveness and dissatisfied builders.
Particular person database branches
Utilizing Lakebase, Jen has the flexibility to department a database for her particular person use and this functionality fully modifications the best way she works.
As a substitute of ready for the shared growth database to develop into out there, Jen creates a database department databricks postgres create-branch for her function or utilizing a VS Code / Cursor Extension. This modifications the form of the work instantly. She is not asking the group for a quiet window. She is not negotiating with different builders about who can run which migration and when. She is not attempting to guard her half-finished change from everybody else’s half-finished modifications. She has her personal remoted database house, created from the identical type of database setting the appliance will ultimately use in manufacturing.
The department offers Jen a quick copy of the database state she must work towards. She now has the identical Postgres engine, the identical schema, the identical governance insurance policies, and the identical production-shaped information she’d see if she queried manufacturing immediately. The one distinction: this department could be modified, discarded, or recreated with out affecting every other workload. She just isn’t testing towards a simplified native database that behaves in another way from manufacturing. She is working with the identical database sort the group makes use of in manufacturing, with the identical sorts of schema guidelines, constraints, indexes, reference information, and migration historical past that make database modifications succeed or fail in the actual world. That realism issues as a result of many database issues don’t seem in remoted unit assessments. They seem when a brand new migration meets current construction, current information, current assumptions, and current utility habits.
Now Jen can deal with the database change as a part of design, not simply as a deployment step. She will strive the apparent model first: add the brand new columns, set a default logic to separate the prevailing column, create a database migration script, replace the appliance, and run the assessments. Then she will be able to ask higher questions. Ought to this migration script work for manufacturing information volumes, is the info high quality in manufacturing the best way her script expects them to be? Is a knowledge migration script hiding lacking enterprise data? Ought to the desire be modeled as easy columns, a lookup desk, or a separate item_information desk as a result of extra data is prone to come later? Will the question sample want an index? Will this design make downstream reporting simpler or tougher? Within the previous workflow, these questions typically get compressed as a result of altering the database is pricey.
Within the branched workflow, Jen can discover them whereas the function remains to be being formed. The DBA can pair along with her to information her on manufacturing nuances and information volumes, thus offering invaluable enter within the design of the answer as a substitute of being an after the very fact reviewer.
Making the appliance and database change collectively
Jen writes the migration script. No matter her group makes use of – Flyway, Liquibase, Alembic, Knex, Prisma – the script lives within the code repo, alongside the appliance modifications. Schema and information migration travels with code.
(That is the Break up Column refactoring – one in all ~70 patterns catalogued in Refactoring Databases, the e book that operationalized the seven practices.)
She applies the migration to her department utilizing flyway migrate. The software runs in beneath a second towards real-shaped information. She updates her repository code to learn and write the three new columns. She runs her take a look at suite. Assessments move towards actual Postgres no mocks, no in-memory substitutes.
If she desires a clear slate to strive a special strategy, she discards the department and creates a contemporary one off manufacturing. One other second. No cleanup tickets. No DBA concerned.
Similar Jen. Similar refactoring. What modified is the potential.
House to fail quicker
The flexibility to experiment is vital. Evolutionary design and growth isn’t just about transferring shortly by way of a predefined guidelines. Additionally it is about studying because the work turns into extra concrete. Jen could uncover that the primary schema design works however creates awkward utility logic. She could uncover that the second design is cleaner however makes migration of current data extra difficult. She could uncover {that a} small normalization resolution now would make future modifications simpler. The primary migration script she wrote the SUBSTRING indexes are off by one. The harmful DROP COLUMN ran earlier than she may confirm the brand new columns have been populated accurately. As a result of she has her personal department, these discoveries are cheap. She will apply a migration, run the appliance, examine the info, roll ahead with one other migration, or reset and check out a special path.
The department additionally modifications the emotional posture of the work. Jen doesn’t must be overly cautious as a result of another person may be relying on the shared growth database. She doesn’t must announce each experiment to the group. She doesn’t have to scrub up take a look at information instantly as a result of one other developer would possibly journey over it. Her department is a protected place for unfinished pondering. It might include non permanent tables, failed migration makes an attempt, awkward take a look at information, and half-formed designs with out creating noise for anybody else.
On the identical time, isolation doesn’t imply detachment from the group’s requirements. Jen nonetheless writes migration scripts. She nonetheless retains the appliance code and database change collectively. She nonetheless runs assessments. She nonetheless expects the ultimate design to be reviewed. The distinction is that she will be able to do the messy a part of the work privately and shortly earlier than asking the group to purpose in regards to the polished model. By the point she opens a pull request, the dialog can concentrate on whether or not the design is true, not whether or not she had a protected place to check it.
That is the important thing shift: the database department offers Jen quick, life like, remoted suggestions that she will be able to additionally get reviewed from her tech leads or DBAs, by displaying her database department. Quick means she will be able to create the setting when she wants it, not when somebody provisions it for her. Sensible means she is testing towards the identical type of database habits that issues in manufacturing. Remoted means her experiments don’t interrupt anybody else. Collectively, these three properties flip database change from a bottleneck into a standard a part of function growth.
Jen can now transfer the appliance and database ahead collectively. Her code department and her database department develop into two sides of the identical job. One holds the appliance modifications. The opposite offers these modifications an actual database to stay towards. As a substitute of ready, coordinating, or pretending with a simplified setup, Jen can design, take a look at, revise, and study. The function remains to be small, however now the database is not what makes it sluggish.
Opening the pull request
Jen commits each the appliance code and the migration script. She opens a PR.
CI does what Jen simply did, however for the group: it creates its personal non permanent Lakebase department, applies the migration, runs the appliance take a look at suite, runs database assessments towards the migrated schema, validates the migration itself (applies cleanly, idempotent, reversible), and posts a schema-diff touch upon the PR displaying precisely which database objects modified.
The reviewer can now see what the schema change does inline with the code that makes use of it, altering their contextual understanding from summary to concrete.
Screenshot of the Department Diff Abstract view from the Lakebase SCM Extension
Reviewing the change
Within the previous workflow, the database evaluation query was “will this break the database?” – gated by a DBA who had to take a look at each change in isolation as a result of each change had production-scale penalties if it received unfastened. Critiques have been synchronous. Schedules collided. The DBA’s calendar turned a queue and generally the DBA would get skipped for “Time to Market” causes.
Within the new workflow, the query is “is that this the correct design?” The DBA has already seen the schema diff posted by CI. They’ve already seen the migration run efficiently towards a real-data department. Jen may also pull within the DBA for a dialogue, to point out what she is pondering of and all the opposite choices she has tried. The DBA can evaluation on their schedule, not Jen’s. They will present evaluation a lot earlier within the answer growth cycle and enhance the answer round information integrity, indexing technique, future extensibility or long-term maintainability, not on the protecting gatekeeping that used to take all their time.
The group evaluations code and database collectively. One PR. One dialog. Similar window.
Merging with confidence
The migration has already been examined towards an actual information department. The appliance has already run towards the modified schema. The schema migration has been reviewed. The CI construct has run the identical precise steps and has been inexperienced for an hour.
When Jen merges, the migration applies to the subsequent setting, the branches for database and code for CI setting and Jen are cleaned up. Thus making certain that the database change is not a release-night shock.
What Jen simply did is the fifth observe from the 2003 essay: steady integration of database modifications.
What Jen’s journey reveals
Database change turns into a part of regular growth. Branching reduces ready, threat, and coordination overhead. Jen’s day by day loop now offers her quick, remoted suggestions on the database layer.
In Half 2 – Jen’s New Playbook, we clarify what lifted and why the compensating layer Jen labored round her complete profession can come out: copy-on-write branching, the structure that makes it work, and the methodology optimizations that observe.
In Half 3 – Jen’s Crew at Scale, we take a look at what Jen’s story appears to be like like when she’s one in all fifty builders, or perhaps she is engaged on a white labeled product, or she is engaged on a modular monolith with a lot of domains inside it – governance at department creation, the DBA reframe, the agent-in-the-loop, and the platform-design work that opens up when the DBA’s calendar is not a ticket queue.
For readers who need the tour of the IDE tooling Jen used on this publish, there’s the Companion: Plugin Walkthrough – the Lakebase SCM Extension for VS Code / Cursor, finish to finish.
Lastly, a Lakebase App Dev Equipment for brokers to make use of accompanied by an e book for people to observe might be launched shortly.
