Developers have refactored code safely for decades. Databases were treated differently: a schema was designed up front and then changed reluctantly, in big risky migrations. Refactoring Databases argues that a schema can evolve just like code, in small, tested, reversible steps.
Evolutionary database design
The core idea is that a database refactoring is a small change to a schema that improves its design while keeping both its behaviour and its meaning. Because many applications may depend on the same database, each refactoring includes a transition period: the old and new structures exist side by side, kept in sync, until every consumer has moved over. Only then is the old structure removed.
The catalogue
Most of the book is a catalogue of refactorings, grouped into categories:
- Structural, such as renaming a column, splitting a table or introducing a surrogate key.
- Data quality, such as adding a lookup table or applying a standard format.
- Referential integrity, such as adding a foreign key constraint.
- Architectural, such as encapsulating a table behind a view.
- Method, for stored procedures and functions.
Each one explains the motivation, the trade-offs, the schema update, the data migration and the changes needed in access code.
Every schema change should be small, tested, versioned and reversible, just like a code change.
Why it matters now
Migration tools such as Flyway and Liquibase, and practices like expand-and-contract deployments, put this book's ideas into everyday use. It's essential reading for anyone splitting a shared database while moving to services.
Key ideas
Schemas can evolve.
A database design doesn't have to be fixed up front; it can improve in small steps like code.
Use transition periods.
Run old and new structures in parallel until every application has moved over.
Version and test migrations.
Schema changes belong in source control and in the test pipeline, alongside the code.
Expand, then contract.
Add the new structure first, migrate consumers, and only then remove the old one.
My take
The book that made database changes as routine as code changes.
On long-lived products I've worked on, the database was always the part people were most afraid to touch. This book gave me the vocabulary and the techniques to change that, and its approach sits behind the database automation I later built into our CI/CD pipelines.
The specific tools have moved on, but the approach hasn't. If your team still treats schema changes as special events, start here.
Who should read it
- Teams with a shared database that's hard to change.
- Architects planning to split a monolith's database into services.
- Engineers setting up database migrations in CI/CD.