You are the only one who has been mentioning OLAP so far. It's just one use case among many.

OLAP is the only use-case where queries that require complex aggregate computations with potentially-unbounded runtimes are relevant. When you subtract GraphQL from SQL, the difference is "arbitrary OLAP reporting capabilities." So I think it's fair to focus on this use-case when talking about what exactly having an SQL API gets you (over having a GraphQL API.)

I'm not really sure what you're trying to communicate here. Arbitrary aggregates are not usually an appropriate thing to expose to users as part of an API. Where they're actually relevant doesn't change that.

Maybe you don't understand the original point of SQL as a language? It's a language where humans—usually, employees who are granted access to data, or customers who are paying for access to data—type up descriptions of reports they want to receive, in a formal language; send it off to a remote system; and then those reports, magically, come back. In between, there can be anything—maybe a bunch of interns manually collating data from thousands of Excel spreadsheets. But usually there's a DBMS, an automated system whose job is to do whatever is necessary to turn the data it has, into the reports people need—no matter how complex a task that turns out to be. Because it's a complex task that needs doing.

I don't think it matters whether you call that "an API"; I think your implicit point here is that "an API" is something that you expose to the general public, and this is ...not that. But if we're talking about the benefit people get from having SQL-shaped access to your data model, then this is what it is: the ability to specify complete, arbitrarily-complex reports that they want your system to calculate out for them.

To me, the entire point of "an SQL API", as opposed to any other kind of API, is that it allows the data in your system to serve the needs of people who need those reports. Other users can be satisfied with pre-defined reports. The point of SQL is to serve the needs of users with arbitrary moment-to-moment needs. Users who need to explore and decompose your data in ways you never considered. Users who need to experiment inside your data model; to investigate it, to audit it.

With any other kind of API, such people would be too constrained by your pre-built possible queries to satisfy their needs; and so would instead need a whole ETL pipeline built for them, to take your raw data out of your system, and put it into their own (OLAP) system, where they could then ask that system to generate their reports.

If you expose an SQL API, you obviate all of that—the customers or employees who need to generate complex reports from your data can just ask your system to go do that.

---

Consider a government agent tasked with auditing Facebook's GDPR compliance. How would they be enabled to do that?

Facebook certainly can't just take an offline dump of the entirety of Facebook's data and give it to the auditor, in order for them to play with it in their own OLAP systems. It won't fit, and that's a GDPR violation in-and-of-itself besides.

Alternately, dumping a random sampling of their data might miss important low-frequency edge-cases.

That leaves online examination of their data.

It's not already in relational form—most of it is in Cassandra, a NoSQL database. So Facebook can't just give them access "to their RDBMS"—they don't have one.

But none of these other systems directly support the kinds of arbitrarily-complex queries the auditor needs to do.

What would Facebook need to build, for this use-case?

Why, an SQL API gateway server, of course—one that wraps their entire data warehouse, allowing the auditor to issue arbitrary SQL queries that reach out to join together and process data from all of Facebook's services.

That's when you have "an SQL API."

---

And there are more use-cases than just "auditors."

If, for example, the reason you're collecting data is to do analytics to it (this is e.g. advertising data), then the point of your business is selling your customers the ability to arbitrarily analyze that data. You might have an online GUI for doing basic BI-style break-downs, but the only "fallback" interface that your customers will be truly satisfied with is an SQL API.