Version upgrade / patch rollback

Symptom

Problems after an upgrade/patch: performance regression, application incompatibility or the database not opening.

1. Stop first: do you have a fallback plan?

If you did not take a full backup + (if possible) a storage snapshot BEFORE the production upgrade, the safest path is to fix forward. In most databases, rolling back means restoring from backup. This step should really have been planned BEFORE the upgrade.

2. Classify the problem

Is it an optimizer plan regression (queries slowed down), an application/driver incompatibility, or a failure to open/corruption? The solution path varies greatly accordingly.

3. Rollback path by database

Oracle: patch rollback with datapatch, or Flashback Database (if you created a guaranteed restore point). PostgreSQL: rollback after pg_upgrade = old binaries + backup of the old data directory. MySQL: in-place DOWNGRADE is generally NOT SUPPORTED — restore from backup. SQL Server: there is no downgrade — restore from the pre-upgrade backup. In every case: the snapshot/backup is your insurance.

4. If it is a plan regression: fix without rolling back

Usually there is no need to roll back the whole version; only the plans have changed.

Oracle

ALTER SYSTEM SET optimizer_features_enable='19.1.0';  -- pin to the old behavior
-- or lock in the good plan with a SQL Plan Baseline

PostgreSQL

ANALYZE;  -- fresh statistics first
-- if needed, temporarily: steer the plan with settings such as SET enable_nestloop=off;

5. Permanent: next time

Test the upgrade in staging with a real workload first, apply canary/rolling upgrades, take a guaranteed restore point / snapshot and document the fallback procedure.