Earlier quoted context omitted.
If you handle large amounts of geographical data you'll need to invest quite a bit to move to Postgres. It's possible but you're going to need to touch a lot of existing code and figure out new performance characteristics and so on. A lot of it will be hard for an average organisation, not because it's very sophisticated and complex but because it will be large amounts of boring rote work that many developers don't s…
PostGIS seems leaps better to me (like the PG DX in other aspects). Eg in Oracle you don't have 2d points. Adding a geo index can fail in the middle and leave the table in a unusable state that requires DBA magic to untangle. Etc. This is just on top of the general technical inferiority (eg there are no transactional schema changes, so you don't get the safe go/no-go in those when applying those as part of app deploy…
You need to decide if and how to perform a rollback, similar to how you would define a down() procedure in migration files. A schema change might imply changes to data, and in that case you might turn off client writes, copy the table, change it, validate, do rename dance, turn on client writes again. If it doesn't it might be much cheaper to operate on a single copy. How does Postgres decide on such strategies automatically?