Database migrations are a user-control problem

As a home-server admin, I’m less bothered by automatic updates than by upgrades that quietly remove my ability to pause, downgrade, or leave. A migration can change the schema so the previous version is no longer safe to run. That should be treated as a user-control issue, not just an implementation detail.

Before upgrading, an application should create a verifiable, portable export and clearly say whether rollback is supported. Nextcloud’s updater, for example, doesn’t back up the database or data directory, and downgrading is explicitly unsupported. A database dump alone may also depend on the application version or omit media and configuration.

Should maintainers be expected to support downgrade paths, or at least stable export/import formats? Share your upgrade failures, counterarguments, or better practices.

I’d separate two promises: reversible upgrade and portable exit. Supporting every downgrade path may be unreasonable, but documenting the limit and providing a tested export format seems like a fair expectation. “We have backups” is not the same as “you can move elsewhere.”

The export needs an integrity check, not just a file appearing in a directory. For something like Immich, the database and original-photo filesystem both matter; backing up one without the other can leave an inconsistent recovery. The checkpoint should cover the whole data model.

Automatic updates win because most owners never schedule maintenance. Add too much friction and people will skip security fixes. My compromise would be a prominent preflight report: export scope, restore status, rollback compatibility, and exactly what the update will change.

A standardized interchange format is more realistic than universal downgrade support. Downgrades require old code to understand new state, while export/import can define a deliberate compatibility boundary. It still won’t capture every extension or permission, but it gives users an exit route.

The dangerous phrase is “backup completed.” A raw SQL dump may restore only with the matching application version, and a product export may omit attachments or configuration. I’d want a documented restore test before calling an upgrade safe.

There’s a cost people are skipping over: maintaining exports and downgrade migrations forever can consume more engineering time than the core feature. I support clear warnings and portable formats, but I’m not sure every small project can promise both. A project’s limits should be visible before installation.