Down Migrations aren't a Myth 🧯

[couling]

I'm currently reviewing the possibility of adopting atlas for our code base. As a general rule I'm pretty impressed. But I am a bit stuck (mostly nervous) on the decision not to have explicit down migrations, not even as an escape hatch.

Reading through your blog post you make many compelling arguments. It's not my intent here to upend your decision. Except to highlight one single point:

I never applied them on a real environment. As simple as that: not even once.

I'm 40 and I've never once seen a fire extinguisher used for anything but training exercises. I'm still deeply grateful for the money spent by every business on checking them and auditing them. However I have had the misfortune to witness the use a down migration in production on two separate occasions. Once three hours after deployment and once a week after deployment. While these were extreme situations, there was also a lot of money riding on getting the system back to a workable state. Down migrations were a much better (less expensive) option than restoring from backup.

Other's may have other use cases for them, but the tested rollback plan for any migration is a strict requirement for some heavily change controlled environments.

We use Postgres, so the issue of dirty state after failed migrations is nearly a non-issue for us.

---

My main concern is that we do occasionally need "destructive" data migrations which have down migrations that cannot logically be inferred from the up migration. They are rare enough but they do happen. We also need to have rollback plans that are non-destructive for some things.

In both cases this means that we cannot simply destroy data. We encounter three situations:

• Up migrations need to transform data into a new layout, down migrations must reverse the transformation. For one theoretical example you might imagine splitting one hyphenated text field out into two columns.
• Up migrations may delete some data, backup tables must be generated and down migrations must restore it.
• Up migrations may add columns or tables. Down migrations must find a place to store destroyed data, even if that just generates a table on the fly.

---

In practice we run into this issue in fewer than 1 in 20 migrations, Atlas could cope with the other 19 just fine. But as we assess migration tools, we need something that works for 100% of our use cases not just 95%. We can't mix and match between migration tools for a single project.

For the most part I really like that Atlas can create the down migration itself. However...

It would be helpful if Atlas had some sort of escape hatch to let users write the explicit down scripts when needed. At least some statements in up scripts need to bring their own down statment. Atlast can't know everything.

[a8m]

Hey Philip, and thanks for the detailed write-up.

You raise good points, and I'd say that in such cases, our current approach is to use a roll-forward strategy, where a new migration is created to override or revert a previous data migration, which also keeps everything auditable.

That said, we're actively working on two initiatives that I think will address your concerns and improve Atlas in general:

• Support for defining explicit down scripts, which can be attached to atlas:txtar files. If a down script is attached to a specific migration, Atlas will validate it and ensure it doesn't result in a divergent state.
• Standardizing data migrations in Atlas. This will include a separate workflow and commands for managing data changes properly (much broader effort).

Personally, I really enjoy these kinds of discussions. I've been working on databases and schema migrations for many years, and posts like yours add useful perspective that challenges our assumptions. If your company hasn't locked in a schema migration solution yet and you're up for a conversation, I'd be happy to chat. Atlas evolves with its customers, and we'd love to see how we can support your needs better - ping me on our Discord if you're interested.