My advice is to never expose the core tables if possible, and only expose views. This way you can change the schema and version your API easily. For example, if you only expose views then renaming a column is as simple as creating (or replacing) a new view rather than a migration.
Another thing we learned is to not tie events (pg_notify) to business logic (no “send customer this email” event for example), but instead have a set of standard events on creation, update, and delete that you fire for all tables, and then run various business logic tasks in response to those. That way you never have to change events or implement new ones.
Read the PostgREST guide, and follow their advice. Good luck!