Doing anything meaningfully complex or mission-critical with either will always require care, attention, and understanding of how the database is doing its work. If you know MySQL internals particularly better, it may benefit you to focus your efforts there as modern MySQL is perfectly capable (decent online DDL support, decent native JSON support, etc).
If your team aren't experts with either, I'd invest my effort in learning Postgres.
Main reason we chose Postgres was that JSON fields have been around for a few years. We really like the Mongo feature-set, but aren't very happy with reliability. In every discussion about Mongo, people used to recommend Postgres instead.
To be honest, I don't like it. I'm not sure if it's bad design, or if it's just bad to mix relational databases with JSON, but I'm constantly battling to do things that I would find trivial in SQL.
I guess it really depends on your requirements though. I've found that JSONb is great for storing historical data and results, write-once sort of stuff. I've found it's not so good for storing objects that get modified, especially if a relation can change.
As someone else pointed out, the reason so many similar tools exist for this task on mysql and there's no such tool for postgres is not that postgres isn't as popular.
The reason is that this problem is almost non-existent on postgres as many table alterations do not lock the table.
But you’re right, my comment is mostly pedantic, that Postgres implements alters better so these tools aren’t needed.
Ultimately I’d always suggest the tool you are most familiar with if it’s doing a good enough job.
1. https://dev.mysql.com/doc/refman/5.7/en/json.html
2. https://dev.mysql.com/doc/refman/5.7/en/create-table-seconda...
