Hoppscotch self-hosted schema migrations and rollback compatibility
0 reputation · 19 Aug 2020, 07:20 UTC
Database Schema State During Version Downgrades
Hoppscotch self-hosted deployments utilize Prisma to manage PostgreSQL schema migrations. These migrations are applied forward during the deployment process to ensure the database structure matches the application version's expectations.
Because Prisma migrations are designed as forward-only operations, rolling back to a previous Docker image tag after a schema change has been applied can create a mismatch. The older application code may encounter a schema containing new columns, renamed tables, or modified constraints that it does not recognize or cannot support.
While pre-upgrade backups are a standard safety measure, this approach necessitates a full database restore, which results in the loss of any data generated between the upgrade and the decision to roll back.
- What is the recommended strategy for maintaining data continuity when a schema-breaking upgrade must be reverted?
- Does Hoppscotch provide a supported path for in-place downgrades without relying on full database restoration?