david on Nostr: One of the great things about neo4j is that there’s really no theoretical upper ...
One of the great things about neo4j is that there’s really no theoretical upper limit to how big it can get. When you do a search using cypher (the query language of neo4j), you can project a subset of the entire graph and run your query only on the subset. So if you’re going to store an event in your db, there’s not much downside to having it represented as a node in the graph along with all its relevant relationships.
A big database like primal or nostr.band — that aims to keep every event that it ever runs across — can keep them all in a massive knowledge graph that is continuously updated, then project that onto smaller subgraphs depending on the query.
For a personal WoT relay, you presumably won’t want to keep every event you ever see due to space constraints. But for those events that you do keep, may as well have them represented in your knowledge graph. In fact, you may want to keep some in your graph db in a pruned form (event id, author, created_at, & kind) even if you don’t want to clutter your event store with the entire event.
A big database like primal or nostr.band — that aims to keep every event that it ever runs across — can keep them all in a massive knowledge graph that is continuously updated, then project that onto smaller subgraphs depending on the query.
For a personal WoT relay, you presumably won’t want to keep every event you ever see due to space constraints. But for those events that you do keep, may as well have them represented in your knowledge graph. In fact, you may want to keep some in your graph db in a pruned form (event id, author, created_at, & kind) even if you don’t want to clutter your event store with the entire event.