I think if you look at traditional databases, yes SQL is the API interface that you use to connect to them. SQL is great for adhoc analysis of data and makes perfect sense when you are writing your data warehouse jobs.
But when you are building an application you would not be writing raw SQL queries, instead, you would be using some kind of a mapping layer (ORM) that can help map the constructs you use during application development to SQL queries. Furthermore, if we look beyond simple CRUD operations and look at other data-related functionality that you might need in your application - search, pub/sub data to an event stream, SQL would most likely not be the interface that you choose because it would be cumbersome.
That's the point I am trying to make, that we need to look at the database technologies from an application developer's perspective and provide APIs that work well in their workflow, something that naturally fits within their code. SQL isn't that API.
In the 1990s there was a fad for replacing mainframe "green screen" applications with "client server" applications that might have been implemented as a desktop application that directly did SQL queries against a database.
It was a notorious failure because of problems with performance and security.
But when you are building an application you would not be writing raw SQL queries, instead, you would be using some kind of a mapping layer (ORM) that can help map the constructs you use during application development to SQL queries. Furthermore, if we look beyond simple CRUD operations and look at other data-related functionality that you might need in your application - search, pub/sub data to an event stream, SQL would most likely not be the interface that you choose because it would be cumbersome.
That's the point I am trying to make, that we need to look at the database technologies from an application developer's perspective and provide APIs that work well in their workflow, something that naturally fits within their code. SQL isn't that API.