Hoppscotch self-hosted schema migrations and rollback compatibility

Short answer

Hoppscotch does not provide a supported in-place downgrade path. Prisma migrations are forward-only by design, so the only officially safe rollback is restoring a pre-upgrade database backup. If you need to preserve data written after the upgrade, you must either design migrations to be backward-compatible before upgrading, or write manual inverse SQL outside Prisma's tooling — which is possible but unsupported and risky.

Why a plain image rollback fails

The self-hosted Hoppscotch backend applies Prisma migrations against PostgreSQL at deploy time. Once a migration has added a column, renamed a table, or tightened a constraint, an older container image starts against a schema it doesn't understand. Typical failure modes are Prisma client validation errors at boot, or runtime query failures on missing/renamed fields. Prisma has no migrate down equivalent: prisma migrate resolve --rolled-back only edits the migration history table, it does not undo schema changes.

What you can actually do

1. Default supported path: backup restore

Take a pg_dump (or volume snapshot) immediately before pulling a new image tag. If the upgrade misbehaves, restore it and pin the old tag. Accept that data written between upgrade and restore is lost — this is the trade-off Hoppscotch's tooling assumes.

2. Preferred operational path: roll forward, not back

Because downgrades are the painful direction, treat the database as one-way and fix forward. Deploy the newer image with a hotfix rather than reverting. This matches how Prisma-based projects generally operate.

3. If you must preserve post-upgrade data: manual inverse migration

Write SQL that reverses the applied migration (drop added columns, restore renamed tables, relax constraints), then mark the migration as rolled back so Prisma's _prisma_migrations table agrees:

-- example only: inspect prisma/migrations/<timestamp>_*/migration.sql first
ALTER TABLE "User" DROP COLUMN IF EXISTS "newField";
-- then reconcile Prisma's state
npx prisma migrate resolve --rolled-back "<timestamp>_migration_name"

Caveats: if the new code wrote data into structures the old code can't represent, that data has nowhere to go. Test the inverse script in staging against a copy of production data before trusting it.

4. Preventive: backward-compatible migrations

Before upgrading, check whether the release's migrations are additive-only (new nullable columns, new tables, defaults). Additive changes usually let the previous image keep running, giving you a rollback window without a restore. Destructive changes (drops, renames, new NOT NULL without default) close that window.

Verification checklist

• Run npx prisma migrate status (or inspect _prisma_migrations) to confirm which migrations the database has applied versus the image you plan to run.
• Diff the target release's prisma/migrations SQL for destructive statements before upgrading.
• Rehearse in staging: upgrade, write test data, downgrade, and observe whether the old image boots and serves requests.
• Verify backup restorability — an untested pg_dump is not a rollback plan.

Uncertainty

This reflects Prisma's well-established forward-only model and general Hoppscotch self-hosted behavior as of my knowledge; confirm against the migration files in the specific release you're moving between, since whether a given downgrade is survivable depends entirely on what that release's migrations changed.