I understand, and the same with PostgreSQL. The only time you might need IF NOT EXISTS is when you are juggling multiple DB update scripts from different develo

I understand, and the same with PostgreSQL. The only time you might need IF NOT EXISTS is when you are juggling multiple DB update scripts from different development branches and want to avoid dependencies (and probably creating a new problem). EDIT: Also, accounting for indexes or other patches applied live on production when firefighting. The update also needs to happen in dev and staging environments, but not explode when the update gets run on production. What terrifies me though is the CONCURRENTLY, which indicates automated DB migrations doing stuff outside of transaction boundaries. This stuff should be rare, to the point it is applied manually under supervision. Any step outside the transaction boundary can fail and needs a recovery plan. And you can't automate it because part of the recovery plan might be to fix the networking glitch to see if your statement failed, succeeded but failed to report success, or is ongoing with an uncertain future. And if you have multiple migration steps, that is multiple intermediate database states that you probably haven't tested your app against (say, timeouts because you dropped a necessary index before creating a new one, hopefully one that doesn't take several hours to build).