Does the use of relational database storage affect the performance of a graph database?

[daodol]

Shouldn't the essence of a graph database be to solve the SQL performance problems of relational databases and the storage problems of relational databases? This graph database engine is still using SQL queries and using PostgreSQL storage. In doing so, is it just what a graph database looks like? Not actually optimized for relational databases?

[BennySobol]

In my experience, this extension works exceptionally well for queries with a well-defined path and consistent hops. It translates these queries into SQL joins efficiently, making it a reliable choice in such scenarios.

However, indexing can be a challenge and is not well-documented. The extension uses native GIN indexes for match (e.g., {} clauses), while B-tree indexes are applied to standard WHERE operand. For example, merging operations must use a GIN index, even if it seems unnecessary in many cases.

For less structured queries — such as finding all leaves of a given root — the extension shines compared to manually writing SQL joins. It performs operations directly in the database by loading edges, sorting them, and applying graph algorithms to find paths. These operations benefit significantly from in-memory processing, as disk-based operations are inherently slower. However, performance can degrade exponentially when traversing large, dense graphs. If your data involves a tree with many dense nodes and long traversal paths, performance may become a bottleneck.

Additionally, the extension supports Cypher queries, a query language optimized for graph operations. Its syntax is specifically designed for graph traversal and analysis, offering a more efficient and intuitive approach compared to traditional SQL.