Surviving a 'Database Down' Crisis

It's **Day 97**. One day, it will happen. You'll run a query, the screen will hang, and Slack will start exploding with "Is the site down?" messages.

Step 1: Kill the Query

Don't wait for it to finish. If your database is a car and the engine is smoking, turn off the key.

-- PostgreSQL command to see running queries

SELECT pid, query FROM pg_stat_activity;

-- Terminate the slow one

SELECT pg_terminate_backend(PID);

Step 2: Identify the Cause

90% of the time, it's one of these:

1. **Missing Index** on a 10M+ row table.

2. **Cross Join** (Cartesian Product) – Day 40.

3. **Locking**: You tried to update a row that someone else was already updating.

Step 3: Communication

Don't hide. Tell your team: "I ran a heavy query that impacted performance. I've killed the process and the site should be recovering now. I'm investigating a better way to pull the data."

Performance Protocol

Never run a complex query on production during "Peak Hours." Use a **Read Replica** (a copy of the database) for your analytical queries!

Your Task for Today

Find out how your company (or a project you admire) handles database backups and emergency recovery.

*Day 98: SQL vs NoSQL—The Real War is Over.*