Agree. I've always thought that PostgREST is an interesting project for some niche use-cases and teams. However, his argument about replacing GET request handling with a new tool that lives outside of/alongside your existing application architecture is not a particularly compelling argument. With properly-factored application code adding a GET (list) or GET-by-id is fairly trivial.

The only complexity I've ever run into there is implementing a pagination scheme that is not the typical "OOTB framework" limit/offset mechanism. I still don't think this makes the argument much stronger.

> I don't understand what's the benefit of adding additional third party code into the hot-path

PostgREST doesn't add an additional third-party library. It replaces one or more third-party libraries: Spring, Django, RoR, etc.

> Also what about caching if people can "craft" random queries and send them straight to your PG instance?

Put the SQL that you would've put into your controller code into SQL functions, expose only those through PostgREST, and call it a day.

> I don't understand what's the benefit of adding additional third party code into the hot-path. Adding yet another endpoint is hardly a lot of work, sometimes even auto-generated and has the benefit of being available in your existing monitoring / instrumentation environment already.

If your existing endpoints already support vertical and horizontal filtering, proper pagination, joining, limiting etc. then you won't get much benefit.

> Also what about caching if people can "craft" random queries and send them straight to your PG instance?

Queries can be blocked or rewritten on the reverse-proxy.

Haven't used postgREST but similar tools and these can useful for small/internal apps where you have trusted users