Skip to content(if available)orjump to list(if available)

Using the expand and contract pattern for schema changes

leetrout

I use this example when I speak about and teach devops trainings.

I call it the migration sandwich. (Nothing to do with the cube rule).

A piece of bread isn't a sandwich and a single migration in a tool like alembic isn't a "sandwich" either. You have a couple layers of bread with one or several layers of toppings and it's not a sandwich until it's all done.

People get a laugh out of the "idiot sandwich meme" and we always have a good conversation about what gnarly migrations people have seen or done (72+ hours of runtime, splitting to dozens or more tables and then reconstructing things, splitting things out to safely be worked on in the expanded state for weeks, etc).

I had never heard it called "expand and contract" before reading this article a few years ago.

What does everyone else call these?

fuzzy2

I’m confused. I thought Expand and Contract was about mutating an existing schema, adding columns and tables, not creating a full replacement schema. But maybe I misunderstood?

What’s in the article, I know as the Strangler Fig Pattern.

jerriep

What you describe is what they describe as well:

> For column-level changes, this often means adding new columns to a table that have the characteristics you want while leaving the current columns as-is.

I think what makes it confusing is that their diagrams depict a completely separate schema, but what they describe is really just altering the existing schema.