few understand just how insanely performant strfry is. it's literally just a web interface to a btree lookup in memory that serves the json string that is also in memory (page cache). no need to parse dynamic sql expressions or anything crazy. sql will never be as performant. not to mention zero-copy-flatbuffer-accessed fields if it needs to do further matching on fields not in the index. i don't see how you could possibly get faster than that. I think it's fair to say nostr has the fastest database on the planet for serving nostr apps. you get this same design when you run damus clients, since we put a strfry-like relay in all of our apps. next version of ios will utilize it more fully. damus android and damus notedeck has it built in from the ground up. gotta go fast!
Alex Gleason's avatar Alex Gleason
Me and @npub1scvy...68d8 did load testing against a bunch of different relay implementations, and so far strfry is in the lead with the ability to support 40k concurrent "users" (according to our K6 test criteria) on a single node. The only downside of strfry is that the database and relay server have to be tied to one machine, so it cannot be scaled horizontally without replicating all of the data across each node. Our K6 setup is here: https://gitlab.com/soapbox-pub/otherstuff-relay-k6
View quoted note →