(This is the Split Column refactoring – one of ~70 patterns catalogued in Refactoring Databases, the book that operationalized the seven practices.)

She applies the migration to her branch using flyway migrate. The tool runs in under a second against real-shaped data. She updates her repository code to read and write the three new columns. She runs her test suite. Tests pass against real Postgres: no mocks, no in-memory substitutes.

If she wants a clean slate to try a different approach, she discards the branch and creates a fresh one off production. Another second. No cleanup tickets and no DBA involved.

Same Jen, same refactoring: what changed is the capability.

Space to fail faster

The ability to experiment is important. Evolutionary design and development isn’t just about moving quickly through a predefined checklist. It’s also about learning as the work becomes more concrete. Jen may discover the first schema design works but creates awkward application logic. She may discover that the second design is cleaner but makes migrating existing records more complicated. She may discover that a small normalization decision now would make future changes easier. The first migration script she wrote the SUBSTRING indexes are off by one. The destructive DROP COLUMN ran before she could verify the new columns have been populated correctly. However, because she has her own branch, these discoveries are inexpensive; she can apply a migration, run the application, inspect the data, roll forward with another migration or reset and try a different path.

The branch also changes the emotional posture of the work. Jen doesn’t have to be overly cautious because someone else might be depending on the shared development database. She doesn’t have to announce every experiment to the team. She doesn’t have to clean up test data immediately because another developer might trip over it. Her branch is a safe place for unfinished thinking. It can contain temporary tables, failed migration attempts, awkward test data and half-formed designs without creating noise for anyone else.

At the same time, isolation doesn’t mean detachment from the team’s standards. Jen still writes migration scripts. She still keeps the application code and database change together. She still runs tests. She still expects the final design to be reviewed. The difference is that she can do the messy part of the work privately and quickly before asking the team to reason about the polished version. By the time she opens a pull request, the conversation can focus on whether the design is right, not whether she had a safe place to test it.

This is the key shift: the database branch gives Jen fast, realistic, isolated feedback that she can also get reviewed from her tech leads or DBAs, by showing her database branch. Fast means she can create the environment when she needs it, not when someone provisions it for her. Realistic means she is testing against the same kind of database behavior that matters in production. Isolated means her experiments do not interrupt anyone else. Together, those three properties turn database change from a bottleneck into a normal part of feature development.

Jen can now move the application and database forward together. Her code branch and her database branch become two sides of the same task. One holds the application changes, while the other gives those changes a real database to live against. Instead of waiting, coordinating or pretending with a simplified setup, Jen can design, test, revise and learn. The feature is still small, but now the database is no longer what makes it slow.

Opening the pull request

Jen commits both the application code and the migration script. She opens a PR.

CI does what Jen just did, but for the team: it creates its own temporary Lakebase branch, applies the migration, runs the application test suite, runs database tests against the migrated schema, validates the migration itself (applies cleanly, idempotent, reversible) and posts a schema-diff comment on the PR showing exactly which database objects changed.

The reviewer can now see what the schema change does inline with the code that uses it, changing their contextual understanding from abstract to concrete.