Postgraphile is fantastic, as is PostgREST and I support them both on Patreon because they have changed my life for the good immensely.
They both delegate the application entirely to Postgres, which can do everything all other GraphQL/REST frameworks can do, with no ORMs, data copying, restarting worker processes, poorly generated SQL, or worse. Both systems can have a dozen workers per gigabyte of RAM, vs a dozen gigabytes of RAM per worker for something like Django.
Postgres can do per-row security, can run functions in Python or Javascript or many other languages, can integrate with FDWs to many external services (like redis or mongo or what have you). Numerous extensions exist to trigger event streams (like to rabbit) work with advanced text analysis and searching, horizontal sharding of many different flavors, the list goes on.
If you have to write an API that's pure logic and no model, then pick your favorite language; I'd probably use either Flask or node. But when does that ever happen? Maybe a small sidecar API on what is generally a large CRUD application with analytics. Everything SQL is perfectly designed to serve. Stitch them together with GraphQL or route the REST off different path prefixes from the frontend ala microservices.
It's a matter of what you know. You have to be proficient in Postgres and SQL to make good use of systems like PostgREST and Postgraphile, and the learning curve is fairly steep if you're not used to writing raw SQL daily. If your team is all PHP/Python/Ruby/whatever devs, it probably makes sense to write your API layer in that language rather than force everyone to learn an entirely different platform.
Furthermore, SQL is horribly un-composable; the lack of any real kind of metaprogramming means you end up repeating yourself quite a bit, or at the very least creating multiple layers of indirection in the form of views. I also find it much more painful to work with FDWs and all the various Postgres integration extensions to do simple things like queuing or caching, as opposed to just using a library in your language of choice (although, admittedly, that might be due to lack of experience).
At the end of the day, PostgREST and Postgraphile are great for quickly prototyping an API when all you have is the DB, but I would personally never use them on a project of significant size. YMMV, of course.
PS, assuming you are who I think you are: Hi! Hope you're doing well. :)
They both delegate the application entirely to Postgres, which can do everything all other GraphQL/REST frameworks can do, with no ORMs, data copying, restarting worker processes, poorly generated SQL, or worse. Both systems can have a dozen workers per gigabyte of RAM, vs a dozen gigabytes of RAM per worker for something like Django.
Postgres can do per-row security, can run functions in Python or Javascript or many other languages, can integrate with FDWs to many external services (like redis or mongo or what have you). Numerous extensions exist to trigger event streams (like to rabbit) work with advanced text analysis and searching, horizontal sharding of many different flavors, the list goes on.
If you have to write an API that's pure logic and no model, then pick your favorite language; I'd probably use either Flask or node. But when does that ever happen? Maybe a small sidecar API on what is generally a large CRUD application with analytics. Everything SQL is perfectly designed to serve. Stitch them together with GraphQL or route the REST off different path prefixes from the frontend ala microservices.