I think there are some similarities between a "GraphQL vs REST" tradeoff and a "SQL vs NoSQL" one. As a rule of thumb I would use a GraphQL API if I (as a serv

I think there are some similarities between a "GraphQL vs REST" tradeoff and a "SQL vs NoSQL" one. As a rule of thumb I would use a GraphQL API if I (as a server developer) don't know my clients and their API access patterns and do not want them to assemble what they want on their own in n+1 requests, particularly if they are somewhere in the internet and would suffer from network latency in each request. Likewise, I (as a database developer) would prefer a SQL database if its clients (e.g. independently developed inhouse applications) and their access patterns are unknown. Conversely, as, e.g., a backend microservice developer, you mostly know the access patterns between a database and its clients, mostly because there there is just one database client per database and both constitute the microservice. So you are safe to choose a NoSQL database here with, say, a document-oriented datamodel that is optimized for that single database client. With regard to the API of that microservice, you also know your clients (i.e. other microservices), so you can also optimize a RESTful (or even GRPC) API for them in order to avoid the over-/underfetching/n+1 problem. Even if you cannot optimize your internal RESTful API to satisfy each of your clients' requests in a single response, network latency is not such a big problem here because clients of a back-end microservice are often somewhat close to it.