If you think about other data structures, we don't feel the need for a specialised database for them either. You don't need a set, map, heap, stack, array, hash

If you think about other data structures, we don't feel the need for a specialised database for them either. You don't need a set, map, heap, stack, array, hash etc database. You can do all of those just using a relational database. It's really not obvious to me why people think graphs need their own database, and I speak as someone who has stored certainly hundreds of thousands and possibly millions of graphs in databases over the years and almost exclusively used either an RDBMS, something like parquet or a key/value store to do it (to great success). I absolutely love graphs in programming and use them all the time but I've never once thought to myself that I would like to have graph semantics in a database over and above the links between relations you get in an rdbms or the links between whatever you like that you get in a key-value store. More concretely I'm pretty sure you could demonstrate using relational algebra that any graph can be formed pretty trivially using relations. So I think there is probably provably no use case that can't be done with a more traditional RDBMS. Likewise it seems obvious that any graph can be stored in a key/value store (bunch of nodes, bunch of edges, badda bing badda boom) and therefore there is similarly no graph db use case that can't be done using a k/v store if that's your thing.