[MadWombat]

> A SQL Schema can carry a custom query, it's called a view.

This is not feasible. I might not have enough access to create views. I might not have access to create functions. I cannot deactivate permissions if I only have a single access account and other systems use it already. You cannot assume that I have full control of the database or that I can easily make changes to the schema.

But this is not all. I am working on a web backend project on daily basis. I would love to offload some basic CRUD operations to something like postgrest or implement GraphQL with something like Hasura, but I need a way to a) define table and field name mappings b) define what tables are accessible b) define what columns are visible c) define what nested relationships are allowed d) define actions that need to happen on update/insert/delete operations (i.e. push a message into a queue every time a record is deleted from table T) If I could do all of this, I could implement about 50% of my web service and it would be useful.

[batmansmk]

Please read the docs. All your fears are addressed in the doc. The permissions are managed on the Hasura side.

Concerning the lack of sufficient privileges to create a view, you can always either ask for permissions, or create a second databse with FDW. Apparently reading your second paragraph you are allowed to create tables, so it sounds like you'll also have enough privileges to create views.

I don't understand your point on your second paragraph. You can do all of that in Hasura, it's in the first tutorial, but also the doc. Please note we are talking GraphQL so there is no CRUD. It is a query + mutation model. More flexible and powerful than CRUD.

[mongol]

Of course, if you don't have that access, it becomes harder and less suitable. BUT: If you have that ability, it is quite good. I think we are going into a SQL renaissance, especially if frameworks like this article is about will succeed in overcoming the classical ORM impedance mismatch