While nobody does it , SQL implementations have network API, authentication, authorization, ACL/RBAC, serialization, Business logic all the things you use in RESTful apis can all be done with just db servers.
You can expose in theory a direct SQL API to clients to consume without any other language or other components to the stack .
Most SQL servers use some layer on top of TCP/IP to connect their backends to frontend .libpq is the client which does this in postgreSQL for example .
You could either wrap that in Backend SQL server with an extension and talk to browser and other clients in HTTP[1], or you can write a wasm client in browsers to directly talk to TCP/IP port on the SQL server
Perhaps if you are oracle , that makes sense, but for no one else, they do build and push products that basically do parts of this .
[1] projects like postgREST basically do this .
In theory, the app servers that sit in front of those databases could just as easily use SQL instead of GraphQL. Even practically: The libraries around working with SQL in this way have become quite good. But they solve different problems. If you have a problem GraphQL is well suited to solve, SQL will not be a suitable replacement – and vice versa.
(If I recall - one of the criticisms of GraphQL is that it's a bit too close to actually just exposing your database in this way)
GraphQL isn't anywhere close to being similar to SQL, so I find the desire for an analogy very confusing.
To me, these are grammars for interacting with an API, not an API.
To me, it is like calling a set of search parameters in a URL an API or describing some random function call as an API. The interface is described by the language. The language isn't the interface.
