Seeing the Trees for the Forest: Leveraging Tree-Shaped Substructures in Property Graphs

Property graphs often contain tree-shaped substructures, yet they are not captured by existing proposals for graph schemas; likewise, query languages and query engines offer little-to-no native support for managing them systematically. As a first contribution, we report on a micro experiment that demonstrates the optimization potential of treating tree-shaped substructures as first class citizens in graph database systems. In particular, we show that in systems backed by relational engines, we can achieve substantial speedups by leveraging structural indexes, as originally developed for XML databases, to accelerate path queries. Based on our findings, we put forward a vision in which tree-shaped substructures are systematically managed throughout the graph query lifecycle, from modeling and schema design to indexing and query processing, and outline arising research questions.

💡 Research Summary

The paper “Seeing the Trees for the Forest: Leveraging Tree‑Shaped Substructures in Property Graphs” observes that many real‑world property graphs contain a substantial proportion of tree‑shaped substructures (e.g., hierarchical locations, tag ontologies, comment‑reply threads, time‑series statements). Existing graph schema proposals, query languages, and execution engines largely ignore this fact, treating the graph as a uniform structure. The authors therefore ask whether recognizing and exploiting these tree components can improve both usability and performance of graph queries.

To answer this, they conduct a micro‑experiment focusing on relational‑engine‑backed graph database management systems (GDBMSs). They adapt two well‑known structural indexing techniques from XML data management—PrePost (preorder/postorder numbering) and Dewey (path‑vector encoding)—to the tree substructures embedded in property graphs. PrePost assigns each node a pair of integers (pre, post) such that ancestor‑descendant relationships reduce to simple integer comparisons; Dewey stores a dot‑separated path string (or vector) that enables ancestor checks via prefix matching. The authors discuss trade‑offs: Dewey is easier to maintain under dynamic updates, while PrePost offers more compact storage and faster numeric comparisons.

Implementation is carried out on three systems: Neo4j (native graph engine), Kuzu (relational engine with separate node/edge tables), and Apache AGE (PostgreSQL‑based). For Neo4j and Kuzu, the structural index values are added as “meta‑properties” on nodes; for AGE they become additional columns in the node table. Traditional B‑Tree or hash indexes are built on these columns. The prototype currently supports only homogeneous trees where all nodes and edges share the same label (e.g., comment‑reply trees).

Three representative tree‑centric queries are evaluated: Q_desc (find all descendants of a given node), Q_leaf (find all leaf nodes under a given node), and Q_a&d (test whether two nodes stand in an ancestor‑descendant relationship). For each system, three query variants are run: a baseline Cypher/SQL query that uses generic path patterns, a version that leverages PrePost predicates, and a version that uses Dewey predicates. The baseline for Q_desc, for example, is `MATCH (n)-