Nostr Web Client

log n isn’t as bad as you think

traversing n = 1B is 2.5x as expensive as n = 10k

now, what cost does this “index free” approach bring compared to indexes? it pushes the storage engine to add a 2nd translation layer for pointers and/or implement compactions with pointer rewriting

all while making your codebase more complicated for no reason

the act of calculating PageRank is significantly more expensive than a few DB lookups.

Jay 2mo ago

I think that arguing about speed and efficiency is missing the point, and why all conversations about graph data go to shit.

Use the schema that fits the domain. If your data is graph data, use a dedicated graph database.

Neo4j is still the correct tool for Nostr. Because Nostr data is graph data. It may not outperform the specific, narrow use cases you think up to dismiss it, but that doesn't matter to me. You need to reframe the way you think about data to see the power of graph representations. And everything you say tells me you can't do that.

Reply to this note

Please Login to reply.

Discussion

semisol 2mo ago

Anything can be a graph database. Even relational databases are one form of graph. We don’t need large, unnecessarily complicated tools to solve the Nostr graph problem.

What does Neo4j bring to the table compared to standard Nostr filters that makes it so useful? That it makes complicated queries look cheap and easy?

semisol 2mo ago

A graph database is one of the most general types of databases (even more than RDBMS) and is by consequence one of the hardest to optimize.

It simply does not make sense for Nostr, where purpose specific databases can allow for graph like queries but much more optimized for the use case (and unlock new capabilties due to that).

Jay 2mo ago

That you can place Nostr events in it in a form that is natural and organic. That you can let the data form itself into the structures that emerge organically by the network that creates it. And that it gives you the right tools to find things you couldn't imagine before you started.

That is why graph data is powerful, and why it outstrips tables and other databases in my mind. There's power in it's inefficiency because you can build on it indefinitely. You set yourself up to build things you can't imagine instead of constraining yourself to what you're building today.

semisol 2mo ago

A product is no good if it is too expensive to run or use.

What *can you really do* with graphs that you can’t do with REQs, even if multiple of them?

Jay 2mo ago

We'll have to see. Like I said, you have to let complex structures emerge before you decide what to do with them.

david 2mo ago

Native graph dbs can execute *performant* path queries that are *long and complicated*.