There is a Prisma command that synchronises your schema to your database without generating a migration. On a fresh development database it is genuinely useful. Run it against a database whose live state has drifted from the migration history, and it may decide the correct way to reconcile the two is to reset.

It reset. Six hundred and four published articles, twelve categories, the media library, and every analytics row went to zero.

What made this survivable

A backup taken forty minutes earlier, for an unrelated reason. That is not a process — that is luck. The part that was not luck: that backup had been restored into a scratch database and verified beforehand. An untested backup is a hypothesis, and the moment you need it is the worst possible time to test it.

What we changed

Schema changes now go through prisma migrate diff --script, which emits SQL instead of applying it. The SQL gets read before it runs. The two blog migrations that followed were reviewed this way, and the review caught real things — one column typed TEXT where the content column needed LONGTEXT, and a nullable widening that had to be confirmed as leaving existing rows intact.

Every migration is preceded by a fresh dump, and followed by a row-count check and a foreign-key check against the tables that were touched.

The honest conclusion

The command was not the problem. Reaching for a convenience tool on a database with real data in it was the problem, and the reason it was reachable at all is that development and production had blurred. Destructive operations should be inconvenient in proportion to what they can destroy.