Whether or not you use a graph DB under the hood, having access to a GraphQL API (https://graphql.org/ https://graphql.org/) is much more elegant than having to

Whether or not you use a graph DB under the hood, having access to a GraphQL API (https://graphql.org/ https://graphql.org/) is much more elegant than having to join together a bunch of separate REST calls or SQL queries. It automatically traverses relationships for you based on the fields you need, and returns only the fields you ask for. So you get exactly what you need, no more and no less. Most GraphQL servers have a GUI explorer query builder too so you just click on the fields you need and it'll construct the query for you. GraphQL can also run on traditional SQL databases, but I think at some point they hit complexity limits and performance issues because JOINs are hard for them, especially if the columns aren't indexed. In a proper graph database, relationships are first-class parts of any data model and there are no "tables" to speak of, just nodes and the arbitrary, complex relationships between them. It makes data modeling both more intuitive (if your data is naturally a graph) and more performant. Here's one take on it (https://developers.mews.com/intro-to-graph-databases/ https://developers.mews.com/intro-to-graph-databases/) At the end of the day there is no magic cure-all for data storage. It depends on the data you're storing and the way you need to read and write from it. And business wise, it may not be worth it to rewrite 10 years of SQL databases to improve performance by a few percent. But if I were starting a new project from scratch, one that involves layers of interconnected data (say, a bookstore with connections between books, images, authors, customers, reviewers, reviews, inventories, third-party merchants, Goodreads entries, different versions for audiobooks and ereaders, multiple books in a series, etc.) it's the kind of thing that would lend itself well to a graph database in modeling, as long as the stack can also be performant and scalable enough for end users. As a web dev "in the wild", we've offloaded the scaling problem to a vendor by choosing to use a headless CMS (GraphCMS, DatoCMS, Contentful, Prismic, etc.; there are many). Some of those use graph databases while others don't, but at the end of the day we don't really care as long we don't hit their complexity limits. They play DB admin, we get GraphQL or traditional REST APIs, and we can build a frontend on top of that.