When you need to integrate with 3rd parties though you're right back to writing traditional backend code. So now you have extra dependencies and a splintered code base.
Yes, this automates boilerplate which is awesome for small, standalone apps, but in my experience I haven't seen months of development time saved with these tools.
I cannot think of a situation where an API only handles CRUD data and lacks any behaviour.
But, If your API really only is pushing data around, ' such tooling is usefull and probably saves a lot of time.
You put an item in table queue using SELECT FOR UPDATE ... SKIP LOCKED and some out of band consumer sends your email.
PostgREST isn't about doing everything in the database it's about doing all the same patterns you already do but with less boilerplate.
I'd add that you also have hard to spec couplings and difficult to manage microservices setup.
Tools like MQTT or paradigms like eventsourcing might help. But those all presume your database is a datastore. And not the heart of your businesslogic.
Comes with native CRUD routes for all your tables but you can also declare your own to refund a transaction using Stripe's API, send an email using Twilio's API...
Here's an explanatory video - https://bit.ly/ForestAdminIntro5min
Those third parties can still talk to the same database. We use this pattern all the time, PostgREST to serve the API and a whole bag of tools in various languages that work behind the scenes with their native postgres client tooling.
Do you tightly orchestrate releases? Or do you simply never change the schema?
I guess you could front it with a reverse proxy if not, but would be nice to have auth built in.