Yes. When we write carefully crafted services that manipulate data based on a set of permissions and rules that make up what Twitter (for example) is, you're basically doing similar things that Postgres is doing when it writes data, it is looking at it's own set of permissions, etc..
So yes that's the exact analogy. We're writing databases on top of databases. Only ours are no-SQL.
GraphQL decouples the API and the database entirely. You can implement graphql as a direct DB access, but it's certainly not the intent. Quite the opposite really, it was designed in not small part to provide the ability to aggregate and re-organise data from multiple sources in a single coherent API.
GraphQL is a relational query language, just like SQL but only less powerful.
Fact is that people always wanted a just database anyway. But with some graphical interface on the front. Once we moved the interface to the client in an SPA, it seems unavoidable that backend will turn database-like.
So yes that's the exact analogy. We're writing databases on top of databases. Only ours are no-SQL.