Gitpod self-hosted upgrade: database migration rollback behavior after partial failure

When upgrading a self-hosted Gitpod installation via Helm, pre-upgrade hooks execute PostgreSQL schema migrations. If the upgrade fails after migrations have partially applied, Helm's rollback reverts only Kubernetes resources, leaving the database schema in an altered state. The official documentation advises taking a full database backup before upgrading but does not provide an automated procedure to revert schema changes.

This creates uncertainty about recovery options: whether re-running the upgrade command can safely complete a partially applied migration, or whether manual SQL intervention is required to restore consistency. Community reports indicate that some failed upgrades have left the database in a state requiring vendor support.

• Can a failed migration be safely retried by re-running the same Helm upgrade command?
• If retry is unsafe, what manual steps are needed to revert the schema to a known good state?
• Is there a documented point-in-time recovery procedure for the database schema that does not rely on a full backup restore?