The only thing worrisome about so many relays running strfry is the attack surface if any serious vulnerabilities were discovered and used against it.

Reply to this note

Please Login to reply.

Discussion

Very true. I think that rs relay for nostr should get more love. 🐶🐾🫡

Reads are faster than writes with sqlite at least

That’s applicable to almost any DB, almost 🐶🐾🫡

Benchmarked against pgsql, for a read-heavy prod you'd want to use sqlite though

Unless something has changed in the last year or two? 😅

And in my own experience, I believe you don't need as much server resources to efficiently power sqlite over a chonker postgres

It all depends on so many factors, that “benchmark” is meaningless. What was the setup, what was the schema, what was the data, what was the cardinality, what access pattern, etc… 🐶🐾🫡

Absolutely. This was just in my own experience with my own project. Only a few tables of json with high cardinality on a basic 1 vCPU and on 1gb ram NVMe vps. It's access patten was read-only as that was only what I wanted to test. I could run the same with less specs using sqlite than postgres. But again this was simply for my own project. I'm sure it might be different for another environment.

Oh yeah, your use case and HW specs are not PG candidate for sure. SQLite 💯🐶🐾🫡

Heh, what they gonna steal? Buncha public notes 😎

Or private

Private notes are encrypted by the client

I don’t think data loss is really the issue since everything on relays is effectively public, but a vulnerability that allows corruption of data or DoS could have a significant impact given the number of relays running strfry.

Right, ya no worries I was just kinda joking, but also, I don't tend to worry about this kind of thing. If there's a vulnerability found, it can be fixed. That's what makes good software even better.