I think it's less a matter of "can you represent graphs in a relational DB" (of course you can), and more about what kind of queries the DB is optimised for. Graph databases are intended for complex recursive queries on relatively unstructured data. You could certainly do that in SQL if you wanted to, but you'll pay for it performance-wise.

Graph query languages also make those kinds of queries much easier to express in the first place.

So the underlying storage is conventional, it's still tuples of some kind, and it's only a matter of how indexes are laid out? Otherwise, I'm struggling to see how it could "optimise" for certain access patterns. How would a typical graph database index be different from a btree access method in Postgres?

I don't know much about the internal details of postgres. But there is a ton of detail underlying "it's just tuples of some kind" and there are lots of ways to implement indices, no? Is it so difficult to imagine that different implementations have different performance properties?

There's also the query planner layer to think about too.

Thank you, I'm well aware that a class of software called "databases" exists

No need for the snark. If you want specific details of how postgres differs from graph databases I have nothing for you. I just find your position that btrees are optimised for every query structure... obviously false on general grounds? Like a thing to do to make recursive queries faster is to store relations as direct pointers of some kind, rather than doing index scans for every level of join.

Perhaps we're talking past each other about the word "optimised".

> I just find your position that btrees are optimised for every query structure

But that is not my position! Postgres has many index access methods: hash, btree, brin, gin, gist, and there are extensions for rum, bloom, skipscans, geospatial indexes such as sp-gist, & vector indexes like ivf/hnws (see pgvector.) I mean, as far as graph databases are concerned, besides pgRouting, there's also Apache AGE which is a graph-"optimised" Postgres.

You should learn more about Postgres and databases in general. See comment above. https://news.ycombinator.com/item?id=43203833 which is closely related to the argument I am actually making.

Fair, and I apologise for misrepresenting it. I should definitely learn more about databases in general!