PlanetScale has Safe Migrations which you can enabled for your production DB (branch). Wondering though whether this will protect against everything mentioned here.

https://planetscale.com/docs/concepts/safe-migrations

Safe Migrations would prevent this completely. PlanetScale also allows you to restore multiple backups in parallel.

really? i've definitely done it before on my local as a quicker alternative to cleaning up the docker container/volume, doesn't seem that bad

ofc i'd think differently if i was also putting write-permission prod credentials into my machine, but luckily i haven't been in many places doing that

I'd suggest reading up on what some of these new database providers are doing to help prevent or fix mistakes like this. Since you mentioned PlanetScale, I'll use them as an example.

1) PlanetScale has IP ACLs, which locks down passwords to specific IP addresses. [1] Additionally, with TailScale or another VPN solution, locking down based on IP isn't necessary foolproof.

2) They also have Safe Migrations. When enabled, it prevents DDL from being run directly on a database. [2] Additionally, using deploy requests for zero-downtime schema migrations also allows you to use reverts, which will revert the migration. [3]

[1] https://planetscale.com/blog/introducing-ip-restrictions

[2] https://planetscale.com/docs/concepts/safe-migrations

[3] https://planetscale.com/blog/behind-the-scenes-how-schema-re...