[shlomi-noach]

Engineer at PlanetScale; If you drop columns that are `NOT NULL DEFAULT <something>`, and then you insert some new rows to your newly-versioned table, then you're in a good spot: when you revert, those columns will get the DEFAULT value on those rows.

If those columns were `NOT NULL` and with no DEFAULT, then you are unable to rewind. The rewind process will make an attempt -- after all, maybe you didn't add new rows; maybe you just deleted or updated -- but if you did INSERT new rows, then the Rewind process will fail (and you will be notified that rewind is impossible).

There's a couple more interesting scenarios, see this doc page for more: https://docs.planetscale.com/concepts/deploy-requests

[omegalulw]

This is why you should put minimal consistency checks in your DB directly. Put them in your storage later instead.

[mixedCase]

That would create an explosion of code to handle edge cases that should never happen when interacting with the DB, or worse, pretending everything's alright and letting everything blow up in your face later.

[cesaref]

So that you can cope with someone messing up a deployment and wanting to roll it back?

Let's say you avoid column restrictions in your db design, and you deploy some dodgy code that doesn't fill in a column correctly, now you've got heaps of dubious data cluttering your database, and apps failing because some precondition isn't being met. That doesn't sound like a good compromise to avoid headaches when updating a schema, does it?

So as ever, it's about making the right decisions on a case by case basis, and there is no 'one size fits all' for stuff like this.