> You'll also have those people that crush the database with poorly optimized queries. GraphQL lets me choose what queries I allow, so no one can lock the database for an hour doing something insane. SQL doesn't give you a lot of tools for that; especially not when some people are supposed to be allowed to lock the database for an hour and others are not.
You don't need a lot of tools for that, but SQL gives you complete tools for it. (Including, if necessary, strictly limiting allowed queries by only authorizing certain particular roles to access a defined set of sprocs without any access to base tables or even views, which seems to be the direct equivalent of what you are suggesting with GraphQL. This is an extremely common enterprise approach.) Because RBAC is standard with SQL RDBMSs (other than embedded/single-user stores like SQLite), it's trivial to handle “some roles are restricted to pre-cleared access patterns and others have either different pre-cleared patterns or free-query access.”
> GraphQL also knows whether the query is a read or write operation;
So does SQL.
> You can sanely route read queries to replicas and pass write queries to the master.
Replicated SQL setups do this routinely.
> This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think).
Well, by definition to route requests to different backends you need a server separate from the backends (or, at a minimum, all but one of them, but you want it separately from all of them in practice anyway.)
You don't need a lot of tools for that, but SQL gives you complete tools for it. (Including, if necessary, strictly limiting allowed queries by only authorizing certain particular roles to access a defined set of sprocs without any access to base tables or even views, which seems to be the direct equivalent of what you are suggesting with GraphQL. This is an extremely common enterprise approach.) Because RBAC is standard with SQL RDBMSs (other than embedded/single-user stores like SQLite), it's trivial to handle “some roles are restricted to pre-cleared access patterns and others have either different pre-cleared patterns or free-query access.”
> GraphQL also knows whether the query is a read or write operation;
So does SQL.
> You can sanely route read queries to replicas and pass write queries to the master.
Replicated SQL setups do this routinely.
> This is harder in SQL, and involves parsing the statements that come through. It's still doable, but again, you'll still need another layer before the SQL server to do it (pgbouncer implements this, I think).
Well, by definition to route requests to different backends you need a server separate from the backends (or, at a minimum, all but one of them, but you want it separately from all of them in practice anyway.)