Migration applied to the wrong database

Migration applied to the wrong database
Type: incident simulation · Topic: Migrations & Releases · Level: L3 · Duration: 10–15 min
Launch: ride postgres start stage-09/07-migration-applied-to-wrong-database

POSTMORTEM (root cause · how it was found · the fix · lesson)
Root cause: a release migration (`ALTER TABLE orders ADD COLUMN release_id`) was
run against analytics_db — a look-alike — instead of app_db, the production target.
The migration "succeeded", so it looked green, but app_db.orders never got the
column and the release behaved as if nothing shipped.

How it was found: comparing information_schema.columns for orders across databases
showed release_id present in analytics_db but missing in app_db; current_database()
confirmed the migration had been pointed at the wrong connection.

The fix: apply the migration to the correct database:
  \connect app_db
  ALTER TABLE orders ADD COLUMN release_id text;

Lesson: a migration is only as good as its target. Verify current_database() / the
connection string before and after running it, and treat a green migration in the
wrong database as the outage it is. Validating the database that already has the
change (analytics_db) or adding an index fixes nothing.

INVESTIGATION HINTS (the staged path to diagnose and fix)
1. The release migration (ALTER TABLE orders ADD COLUMN release_id) reported success, but production still behaves as if it never ran. Check which database actually got it: compare information_schema.columns for orders in app_db vs analytics_db.
2. The migration landed in analytics_db (a look-alike), not app_db. A green migration in the wrong database is still an outage. Always confirm current_database() / the connection target before and after a migration.
3. Apply the migration to the real target: \connect app_db; ALTER TABLE orders ADD COLUMN release_id text. Validating analytics_db (where it already exists) or adding an index proves nothing.