This has been happening for decades in the RDBMS world – even the ultra-conservative Oracle admins I've worked with were willing to come of out in-place retirement long enough to do something like that.
How many DBs do you have? Testing (usually local), staging, production? For how many sites?
It works the same, if row['new_field'] do_something() else do_something_else()
You have unit tests to make sure it works.
And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
In your experience, perhaps, but that's reversed in many other places.
As for everything else your point is only accurate if you assume that migrations are done by hand. If use a migration library it's impossible to forget to apply a migration to a database so there's no problem working with copies or even forks of databases.
> And if it was so safer and easy to do it PostgreSQL wouldn't have added the json field.
You're implying causation incorrectly: hstore and JSON are useful for cases where you explicitly do not want schema enforcement or can't afford the performance impact of normalization. This is not saying that migrations are hard, merely that not all problems have the same best solution.
(Of course, not only migration issues, but any code issues as well)
People migrate tables a lot bigger than 23M rows all the time. On MySQL, even, though it's an offline task there.
Not if your application is still on development.
100k+ rows? Not complicated. Try with 23M rows.
Nobody would risk migrating that table.