Airflow 2.6 db upgrade failure leaves no supported rollback path — how to recover the metadata database safely?

Recovery steps for a failed airflow db upgrade in Airflow 2.6.x

The safest and officially supported recovery is to restore the metadata database from a pre-upgrade backup, because Airflow 2.6 provides no airflow db rollback or Alembic downgrade via its CLI.

Why a manual Alembic downgrade is risky

• A migration can fail after applying DDL; the alembic_version table is only updated on success, so the recorded revision may lag behind the actual schema.
• Data-altering migrations may not reverse cleanly, leaving orphaned tables or inconsistent rows.
• Many Airflow migrations are not idempotent; re-running them after a partial apply often yields "table already exists" or similar errors.

Safe recovery sequence

1. Stop all Airflow services – scheduler, webserver, workers, triggerer – to prevent writes to an inconsistent schema.
2. Restore the metadata database from the snapshot or backup taken immediately before the upgrade attempt.
3. Verify the restored state – run SELECT * FROM alembic_version; and compare the revision to the expected pre-upgrade version for your Airflow 2.6.x release.
4. Diagnose the original failure – examine the upgrade error log; common causes are insufficient DB privileges, lock timeouts on large tables, or an incompatible database version. Fix the root cause before retrying.
5. Retry the upgrade with airflow db upgrade while all services remain stopped.

Verification before restarting services

• Run airflow db check to confirm schema consistency with the installed Airflow version.
• Start only the webserver and confirm the UI loads DAG list, connections, and task instance history without 500 errors.
• Once the webserver is healthy, start the scheduler and triggerer.

If you do not have a pre-upgrade backup, please provide the exact error message and the revision ID from the failed upgrade so we can assess whether a manual Alembic downgrade might be attempted.