Pressing F to pay respects. R.I.P. in pieces

Depending on how mission critical your data is...Set up delayed replicas and backups (and test that your backups can actually be restored from). Get a second pair of eyeballs on your query. Set up test environments and run it there before running it in production. The more automated testing you put into your pipeline, the better. Every edit should be committed and tested. (Kubernetes and GitLab Auto DevOps makes this kind of thing a cinch, every branch has a new test environment set up automatically)

Don't beat yourself up too much though. It happens even to seasoned pros.

I don't know if it makes you feel better but Tom Scott had a similar experience: https://youtu.be/X6NJkWbM1xk

This is about the one thing where SQL is a badly designed language, and you should use a frontend that forces you to write your queries in the order (table, filter, columns) for consistency.

UPDATE table_name WHERE y = $3 SET w = $1, x = $2, z = $4 RETURNING *
FROM table_name SELECT w, x, y, z

Things like this make me glad I can only query my db.

If it's Microsoft SQL you should be able to replay the transaction log. But you should be doing something like daily full backups and hourly incremental or differential backups to avoid this situation in the first place.

Unrelated, but use placeholders instead of interpolation right into the query.

See: Little Bobby Tables. https://xkcd.com/327/

Ctrl+z bro

Jk, sounds tough

I know it's too late to be helpful now, but I always write the WHERE first, because you are not the first person to have done this...

SQL scouts credo: I will never use indexes, I will always use column names.

I‘m using DataGrip (IntelliJ) for any manual SQL tomfoolery. I have been where you are. Luckily for me, the tool asks for additional confirmation when doing any update/delete without where clause.

Also, backups are a must, for all the right reasons and for any project.

I learned this lesson too