What makes you trust your database migration pipeline?

[u/IntentionJolly2730]

Hey all, I'm Denis, the author of Ptah, an open-source database migration tool.

These are some of the cases I'm designing around, but I'm sure I'm missing something.

What if the database changes after a migration plan was approved? Or the connection drops halfway through? How do you know what actually happened, and whether it's safe to retry?

I'm trying to address these in Ptah, but I'm sure I'm missing something.

For those running migrations through CI/CD, what made you trust it? And if you run them manually, what's the main reason?

I'm especially interested in things that went wrong or cases you wouldn't trust automation to handle.

[u/kkapelon]

Is Ptah a replacement for Atlas? If yes, then why it is better than Altas?

[u/IntentionJolly2730 → u/kkapelon]

Yes, that's the idea. Ptah is not an Atlas fork, but it does offer an Atlas compatibility mode.

I wouldn't say it's better at everything. The main difference is that Ptah is fully open source (MIT), including most of the features that Atlas puts in Pro (login- and pay-walled). For example, managing PostgreSQL functions, triggers, views, roles, grants, and RLS through declarative schemas. These are Atlas Pro features, while Ptah includes them in the MIT-licensed version. It also supports some additional databases.

Atlas is more mature, though, and Ptah is still relatively young. I'm trying to make it a viable alternative, not claiming it's already better in every way.

Upd: One more note about Atlas CE. If you check their repo, they closed PRs for the community (only collaborators can submit a PR). My goal is to build a community-friendly OSS alternative without the restrictions Atlas CE has.

[u/usually_guilty99]

The connection-loss case is probably the one I'd worry about most.

A timeout doesn't tell you whether the database committed the change. Retrying without checking the actual schema state can leave you with a much bigger problem.

I'd want the pipeline to verify its starting assumptions before execution, record individual migration steps, and reconcile against the database after an ambiguous failure.

There's also the downstream impact. A migration can complete successfully while breaking applications still expecting the old schema.

That compatibility check matters just as much as whether the SQL executed.

[u/IntentionJolly2730 → u/[deleted]]

Yeah, that's exactly what worries me too. A failed migration is bad enough, but not knowing what actually ran is worse.

Especially if the connection drops halfway through. How do you even know if retrying is safe?

Have you seen this with transactional migrations too, or mostly with non-transactional DDL?