[emodendroket]

I remember having a test suite that would connect to a local db running in a docker container and would nuke the tables and then set up the records in a known state before running through. Worked great until someone changed the connection string to point at an actual database.

[DaiPlusPlus]

One possible trick you might consider is to (manually!) add objects to the DB's schema that explicitly indicate its environment, e.g. `CREATE TABLE dbo.ThisIsProductionYouSillyPerson ( DummyCol int NOT NULL );` for prod and `CREATE TABLE dbo.ThisIsTestFeelFreeToMessAround ( DummyCol int NOT NULL );` - these tables would be excluded from the automated DB deployment code - and write test scripts that all start by checking that the `dbo.ThisIsTestFeelFreeToMessAround` table exists and that the `dbo.ThisIsProductionYouSillyPerson` table does not exist in the DB before continuing.

DB automation is great for preventing mistakes during common routine operations, but because DB automation can also go haywire and delete drop all-by-itself unless you set-up out-of-band (if that's the right term?) safeguards. Having airgapped dev-test-staging-and-prod won't help you if if you forgot the `WHERE` in an `UPDATE` in a little-used script that the prod automation uses, that testing never discovered (which happens all the time, it's scary).

I do appreciate how MySQL does come with an `UPDATE-without-key` guard, but I'm surprised none of the other RDBMS have safety-guards like that - just a simple `RequireManualConfirmationForMultiRowDml` flag on a table would help.