Which Helm hook strategy ensures zero-downtime during database schema migrations?

When migrating a small application using Helm, the goal is to perform database schema updates without interrupting traffic. While Kubernetes RollingUpdate handles the pod replacement, the timing of the schema change relative to the application deployment is critical.

Using a pre-upgrade hook allows a migration job to run before the new version of the application is deployed. However, if the new schema is not backward-compatible with the currently running pods, a window of failure may occur between the hook completion and the full rollout of the new pods.

Given that Helm hooks are independent jobs and not integrated into the Deployment's readiness probes, how can a release be structured to prevent the RollingUpdate from starting until the schema is verified, while ensuring old pods remain functional during the transition?