I have a layer of indirection between my end user API and my underlying storage, so that I can change the storage without changing the API. There's no pain involved.
> I don't want to avoid [coupling my application schema to my database schema]
It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up. (I think your indirection layer is a good idea; I’m curious what your previous post meant in light of that.)
> It seems like you built a layer of indirection to specifically allow the thing you said you didn’t want to do a couple posts up
No, because my layer of indirection is in the database in the form of views and procedures. I could be wrong, but I took "coupling my application schema to my database schema" to be something like "having your HTTP API depend on objects in the database", which it does because of the way that postgREST works. If that's the kind of coupling we're talking about, then that's the kind of coupling I would rather embrace than avoid.
Perhaps what you're asking is, "Why not just have your user interface connect directly to PostgreSQL and issue SQL statements?"