I was wondering which would be more appropriate / idiomatic when writing a Helm-Chart:

  1. Perform long running operations (such as db-migration) as part of the helm install process via helm hooks and inform the users that a longer --timeout is needed
  2. Perform long running operations as a Kubernetes-Job

Edit: I'm talking about db-operations that can take many hours to complete

1 Answer 1


A helm hook pretty much has to be a Job or Pod. Thus choosing between using a hook or using a Job doesn't make much sense - you are usually best off using a Job which is annotated as a pre-upgrade hook.

And yes, the timeout probably needs to be increased by the users. Unfortunately it's not possible to define the timeout in the chart itself.

In some cases it makes sense to have a db upgrade happen after the helm chart has been applied and in that case it can be a "normal" Job. This pattern however requires coordination between the Pods accessing the DB and the upgrade process such as a table in the DB which declares the version(s) of the schema.

  • How long would you say it's okay for a Helm hook to run? Let's say the migration takes 10 hours, or even 3 days. Would you implement that as a synchronous hook or would that scenario cause you to prefer a normal, asynchronous job (that is coordinated with the actual application Pods)? Jan 17, 2022 at 12:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.