EdgeDB is built on an extension of the relational data model that we call the graph-relational model. This model completely eliminates the object-relational impedance mismatch while retaining the solid basis of and performance of the classic relational model.
I don't see how can they retain the performance of the relational model when using graphs on top of PG unless they are using PG as storage k/v layer only.
The key insight here is that we still have schema. We have high-level object types and a first-class notion of a "reference" - we call it "link". Our other extension of the relational model is that every "row" must have a unique ID. Both things combined implement a graph or your types and a graph of your data as it's stored in the underlying tables. Everything is strictly typed and efficient.
But EdgeDB isn't ideal for storing loosely typed graph data, neo4j is built for that.
Can use these techniques on top of typical, existing relation model tables as well. Consider a join table, or even a polymorphic join table, that gives you the edges. But you can use unions and stuff to join up data across various tables. Can get really creative with it.
I don't see how can they retain the performance of the relational model when using graphs on top of PG unless they are using PG as storage k/v layer only.