What Martin Fowler's Evolutionary Database Design Taught Our Migration Agent

Martin Fowler is one of the most widely read authors in software engineering. His bliki, his books (Refactoring, Patterns of Enterprise Application Architecture, NoSQL Distilled), and his work with Pramod Sadalage on database design have shaped how a generation of engineers think about change. The specific body of work we keep returning to at Data Workers is his writing on evolutionary database design — the discipline of treating schema evolution not as a once-a-year crisis but as a continuous, incremental practice.

This post is about what we learned from that work and how we encoded it into the dw-migration agent. It is not affiliated with or endorsed by Fowler. It is homage: an attempt to give honest credit to ideas that genuinely shaped how we think about a hard problem.

What Is Actually Worth Learning

Fowler and Pramod Sadalage documented evolutionary database design over years of ThoughtWorks project work. The central insight is simple and radical at the same time: a database schema can be refactored, not just replaced. Fowler defined database refactoring as "a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior" — borrowing the exact definition from his code-refactoring work and applying it to schemas.

Three principles from that body of work do the real work in practice:

• •Every change is a numbered migration, tracked in a changelog table in the database itself. No hand-applied DDL, no tribal knowledge about what schema the staging environment is actually on. Schema state becomes deterministic and auditable.
• •Parallel change (also called expand and contract) over hard cut-over. For any breaking schema change, you expand first — add the new column or table while the old shape stays live — then migrate all consumers to the new shape, then contract by dropping the old. You never pull the rug out from under a running system.
• •If it hurts, do it more often. Fowler's incremental migration principle holds that running migrations every iteration, rather than once at go-live, transforms data messiness from a launch-week crisis into a routine discovery.

There is also a fourth pattern that Fowler named earlier, which we apply at the warehouse level: the Strangler Fig. Rather than rewriting a legacy system wholesale, you build the new system at the edges and gradually move behavior across until the old system withers. Applied to a warehouse migration, this means: do not flip 400 tables on one weekend. Start with the tables that have the fewest consumers, validate those, then advance.

How a Method Becomes a Skill

The dw-migration agent already had an incremental-migration skill built on first principles. When we ran the mimeograph process on Fowler's work, we found the overlap was high — and the gaps were instructive.

What was missing was the explicit parallel-change gate: the agent would translate objects and then validate them, but it had no formal expand-phase step that held the old schema live while consumers migrated. For any object with external consumers (Looker dashboards, downstream ETL, partner feeds), a direct cut-over is a breaking change disguised as a migration. Fowler's expand-migrate-contract sequence makes the risk explicit and gives the agent a decision point: if a consumer list is unknown or externally owned, default to parallel change, never direct cut-over.

The result maps Fowler's method directly onto the agent's available tools: assess_migration to build the dependency graph, batch_translate_sql to generate each numbered migration, run_parallel_comparison as the evolutionary gate, and validate_migration as the contract-phase gate before dropping old objects.

One of More Than 400

The evolutionary-database-design skill is one of more than 400 method-named skills across 19 agents in the Data Workers swarm. Each skill follows the same pattern: a public body of expert practice, distilled into triggers, steps, and decision points that wire directly to the agent's available tools. The skill is named for the method, not the person.

A note on this post: This is independent commentary and homage. It distills publicly available writing and talks by Martin Fowler to illustrate a working method, and every quote is drawn from and verified against the primary sources linked above. The skill it describes is named for the method, not the person, and contains no marketing claims attributed to them. Data Workers is not affiliated with, sponsored by, or endorsed by Martin Fowler. If you are Martin Fowler and would like anything adjusted or removed, email hello@dataworkers.io and we will respond promptly.