"Y'all are having a dick-measuring contest about the speed and the size of your DB 🙄." I laughed there because that is mostly true. Many relay devs are focusing on who can do it faster or whatever. But also, if it can't store a TB of books, is it really going to be able to handle when Nostr actually becomes big?

With NFDB, one of the core focus has been usability. Many features on nostr.land are only possible because NFDB is easy to use and has a bunch of features most devs do not need but are absolutely required in large-scale relays.

The performance and reliability are just there so I can offer more without it costing as much as an AWS bill. :)

They all solve different problems. Realy/strfry are good for small-medium scale but are basically one-trick ponies and require a special proxy layer on top to do anything. (and then eventually that isn't enough either)

NFDB tries

NostrDB is good for small-scale local caches because it builds indexes of profiles and other "important" data.

Custom solutions can do a lot more with less though. Think for a day, what does my app need, and make a database schema. Cache what you actually care about that way and it'll do better than any cache relay.