Connected to the wrong database

Connected to the wrong database
Type: incident simulation · Topic: Multi-Database · Level: L2 · Duration: 10–15 min
Launch: ride postgres start stage-06/01-connected-to-wrong-database

POSTMORTEM (root cause · how it was found · the fix · lesson)
Root cause: the cluster hosts several look-alike databases (app_db is production,
analytics_db is a copy). The production app was stuck in maintenance mode — a flag
in app_db.db_identity — but it's easy to investigate (or "fix") the wrong
database, because the tables look identical.

How it was found: SELECT current_database() and the db_identity marker reveal
which database you're actually in; the maintenance flag had to be cleared in
app_db specifically.

The mitigation: clear the maintenance flag in app_db (not analytics_db).

Lesson: in a multi-database cluster, always confirm the target database before you
act — current_database(), an identity marker, the connection string. Fixing the
wrong database changes nothing in production (and may corrupt a copy). An index is
irrelevant.

INVESTIGATION HINTS (the staged path to diagnose and fix)
1. Confirm which database you're actually in before changing anything: SELECT current_database(); and read its identity: SELECT * FROM db_identity; This cluster has several databases that look alike.
2. The production app lives in app_db; analytics_db is a look-alike copy. The maintenance flag must be cleared in the RIGHT database. Switch with \connect app_db and check SELECT * FROM db_identity;
3. In app_db, clear the flag: UPDATE db_identity SET value = 'off' WHERE key = 'maintenance_mode'; Don't touch analytics_db, and don't add indexes — this is a wrong-database mistake, not a query problem.