django-icv-tree stores a hierarchy as a materialised path: every node keeps a single indexed column encoding its full ancestry, such as 0001/0002/0001. There is no separate closure table and no nested-set left/right bookkeeping to rebalance on every insert or move.
Because the whole ancestry lives in one column, every traversal shown on the main demo page is a single indexed query, not a recursive common table expression: ancestors are a prefix match walking the path upward, descendants are a prefix match walking it downward, and a descendant count is one COUNT query against the same index.
The trade-off is that moving a subtree means rewriting the path of every node under it, which is one bulk UPDATE rather than a cascade of pointer changes. For a catalogue tree that changes rarely and is read constantly, such as the package hierarchy on this demo, that trade-off runs the right way.