Automated schema migrations

When a schema change is made in a data contract you might want to think about how you can automate the deployment of that and migration to it, without data loss or effort from the consumers.

For non-breaking schema changes, for example adding a new optional field, that’s certainly achievable, and having that automated would allow data producers to make that change with autonomy whenever they need to.

But what about breaking schema changes?

The size of a breaking schema change varies, and could be removing a single previously required column to a large scale change of the data structure.

Because of that variety, I don’t believe they can be automated.

But I’ve found this to be a feature, rather than a limitation.

Because of the effort involved, I’ve found data producers spend more time considering the schema at the design phase, with their consumers, to try to limit the need for a breaking change.

And then when a breaking change is required, it forces the data producers to talk to their consumers about the migration, which again increases the communication between those two groups.

It’s a great example of how friction encourages the behaviours we want to see.

Not everything can be automated. Sometimes that’s a feature.