Most graph databases only offer an advantage in query language, as it allows for more ergonomic graph traversal compared to e.g. recursive CTEs in SQL. However with SQL/PGQ, the same query ergonomics are coming to traditional databases.
If you look under the hood there is usually nothing special about graph databases that will make them more performant. If you lay out a query plan side-by side between e.g. Postgres and Neo4J, they will look identical, just that the leaf-nodes in Postgres will be a table-scan, while in Neo4J they will be either a vertex-scan or a edge-scan (which can both be seen as special cases of a table-scan).
As someone that has worked a lot with graph databases in the past, I'd largely recommend not using them. The price you pay in terms of worse ecosystem and less battle-tested maintenance tooling is not worth it to just have better syntax.
Apache AGE seems like a good way to have the battle testedness of Postgres with a more fluent query language. I have only used AGE in smaller projects so far however.
AGE actually looks very interesting. When I evaluated it a while back it seemed like the project wasn't very active and I couldn't find any information about folks using it at scale in production. If I was forced to use a graph database again, and I didn't immediately quit upon receiving that news, I might give AGE a look.
But only just. It doesn't really replace graph databases. It's mostly a slightly more convenient ways to write certain kinds of queries, but it doesn't come with anything else you might expect from a graph database.
If you look under the hood there is usually nothing special about graph databases that will make them more performant. If you lay out a query plan side-by side between e.g. Postgres and Neo4J, they will look identical, just that the leaf-nodes in Postgres will be a table-scan, while in Neo4J they will be either a vertex-scan or a edge-scan (which can both be seen as special cases of a table-scan).
As someone that has worked a lot with graph databases in the past, I'd largely recommend not using them. The price you pay in terms of worse ecosystem and less battle-tested maintenance tooling is not worth it to just have better syntax.