> But why? Are you making schema changes that frequently? Because it makes the migrations much more robust and way easier to develop & test. If something goe

> But why? Are you making schema changes that frequently? Because it makes the migrations much more robust and way easier to develop & test. If something goes wrong in a migration script, everything is rolled back. You edit the part that caused the error and simply run the whole script again. And despite of thorough testing, there is always the possibility that it fails when applied in production. You want that migration to be completely successful or not at all. Think e.g. splitting a table into two (which also includes DML) or moving columns around while creating new foreign keys. You might not need to put the whole migration into a single transaction, but at least combine some steps into one - but this is only possible if the DDL statements are transactional.