nostr:nprofile1qqspg8fq209jj56663d2n6r9ehkyjffy7rkqqejfdwvtwzva426avkqppemhxue69uhkummn9ekx7mp0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qghwaehxw309aex2mrp0yh8qunfd4skctnwv46z7w50vhn can you share your thoughts on the thread here?
Gary have you used neo4j? I see it mentioned in this article. At nostr:nprofile1qqstu7l4mcrgc8vy9mf55lp8q5r7e9q0t6j3vuw06p32jh5ap9pq6zsppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uk5mhhr we’re looking at building a nostr graph database relay and neo4j is our top contender.
Discussion
Been a long time (~10 years) since I've looked at any graph database, and I've never used Neo4j (I remember fighting with Giraph though, had a hell of a time getting that to compile).
I like this paper's assessment of graph databases: https://db.cs.cmu.edu/papers/2024/whatgoesaround-sigmodrec2024.pdf
TLDR is graph databases do have some performance optimizations over RDBMS due to the storage layout and optimized algorithms for common queries (shortest, ancestors, etc), but ultimately you can also represent a graph as a collection of tables. Recently some RDBMS systems have been adding graph-like query languages and have been optimizing joins for graph queries and they have been claiming better performance.
If you're not doing large OLAP queries or using it for other purposes, Neo4j seems like a pretty good fit for a Nostr relay.