We used the "WITH RECURSIVE" basically the moment it shipped in Postgres for the original CoreOS Clair[0] data model which was a graph of software versions and

We used the "WITH RECURSIVE" basically the moment it shipped in Postgres for the original CoreOS Clair[0] data model which was a graph of software versions and vulnerabilities. It scaled well compared to a naive graph abstraction implemented outside the database, but when performance wasn't great, it REALLY wasn't great. After running that version in production for a couple years, we ended up throwing it out and remodeling the domain to be less graph-y to achieve more consistent performance. I've since worked on SpiceDB[1] which scales much better by taking the traditional design approach for graph databases and only treating Postgres as triple-store. IME, there's no short-cut: if you need a graph, you probably want to use a database optimized for graph access patterns. Most general-purpose graph databases are full of optimizations for common traversals that are uncommon operations in relation databases. [0]: https://github.com/quay/clair https://github.com/quay/clair [1]: https://github.com/authzed/spicedb https://github.com/authzed/spicedb