well, i'm so used to building badger based databases i have a bunch of libraries for it, to manage building keys and and generating indexes. doesn't take me that much longer to make an embedded, dedicated database with some particular set of tables this way compared to learning some yet another new thing to work with antiquated sql query engines. i mean, it's just my thing, building things like this so yeah. i write the encoders and the database engines and the network schedulers. offloading stuff to inherently slower, less efficient, less scalable fixed-purpose flexible database engines just doesn't make sense for me, and when you see how fast it returns results the reason is clear. IMO, nostr is a unique enough type of network connected database protocol, so open ended, that using generic general purpose parts to build it is a big sacrifice in performance.

This is a fair take

If you are interested, you can open a PR to nastro adding your own badger based DB. I would actually really appreciate it. The prerequisite is just to satisfy the store interface, expose the internals (so people can make queries directly if needed), and allow for customisation. I think it would be quite beneficial to the ecosystem to move away from the event store fiatjaf packages, which is quite crappy