so, you are aiming for low latency and availability
these are not metrics that have a big factor of the relay's code quality in them, more about the quality of servers you are running on
as for extensibility
lol, you will extend realy in a matter of days and even less if you already have Go experience
i don't shit on the popular languages for nothing, they are all hard to learn, complicated, cost a lot in development and are slow in the test cycle
the underlying DB matters too, in this case, it uses an external K/V DB that handles scaling, and can distribute load to multiple servers instead of one disk
which allows scaling way higher than 1 server’s disk or CPU
the amount of latency added is negligible compared to a local DB
i can see how that would be a plus... i have pondered a lot the idea of making relays able to use othre relays as second level stores, i already wrote the code so that whatever comes back from the layer2 is cached and is found faster from the relay event store
also, yeah, K/V stores are the best... it's really not worth the time to market advantage of generalised sql/graph databases unless the data really is of the kind those DB architectures are faster for
for nostr, KV is teh only way, the indexes are super simple and there's just no reason to extend it unless you want to implement this "DVM" bullshit, which is really just fucking full text search and maybe image/video classifier shit that AIs could probably help with
people are so hyped about AI but really it only improves image, voice and video recognition, that's good, and all, but lol, it's not skynet, gimme a break, fucking morons in fiat corporate VC land
I will check out realy, at least for replacing parts of go-nostr and khatru as I don’t really like it
NFDB is just an event store, the extensibility part is for modifying the query pipeline and indexing
the indexes use a fully pluggable provider, and it is really easy to change things, such as to add search indexes
