Clarification on automigrate option within k8s helm chart

one ambiguity arose on automigrate option while trying to put hydra helm chart to life into some production grade k8s (meaning more than 1 pod replicas) . According to hydra docs (the part where releases specifically instruct running migrate on db initialize or upgrade). I assume migrate is not idempotent operation and as such I see not safe to put into initContainer.

Or am I wrong and operation is safe to run on every redeploy(i.e. at hydra upgrades) and all replicas in k8s cluster? Seems initContainer logs suggest this - observed at hands on test - i.e. redeploy to same hydra version gives information on 0 changes to be performed in db and initContainer exits successfully:
The following migration is planned:
Successfully applied 0 SQL migrations!

Or it is expected to toggle option enabled manually only at explicit systemOps intention as release instructs?

Or even more conservative - doing migrate only from some ‘outside k8s’ hydra instance and also not ‘live’?

If this last is true, what about using helm hooks (pre-install, pre-upgrade) and run migrate as a job?

Thanks in advance and kind regards

It is safe to run migrate more than once on the same DB snapshot. I’m not 100% sure if there could be an issue where to migrate commands run concurrently and both try to migrate the DB - this might cause some issues.

In general all of that really depends on your environment. Of course, manual “outside-of-cluster” upgrades are probably ops best practice because it allows you to do backups before and remedy any issues right away (because of the manual step). A manual step does not necessarily have to run on a dev machine, it could also be in the CI with some manual job approval of some sort.

So it’s really up to you and your requirements.