Used the provided pricing, yes. I assumed that Nosflare uses the same set of indexes (NFDB supports composite indexes, I do not think Nosflare does) and based it off of Nostr.land’s read amounts.
The CPU time was not too relevant, with a huge chunk of it being D1 read costs.
I won’t get into the fact that D1 is probably one of the buggiest products to come out of CF
Is NFDB open source?
No.
But the hosted pricing will be available soon.
Ah ok, let me know if you do open source it, would love to check it out.
Yes, am also using composite indexes. Nosflare is FOSS, so feel free to checkout the source 👍
I am planning on running full benchmarks myself using local versions.
The code looks pretty decent.
CF Workers and D1 are still not optimal for hosting relays, in my opinion. SQLite in general performs poorly compared to local KV-store based solutions, and D1 has its own issues.
And JS is kind of a terrible runtime for an application like a relay, which does a lot of memory allocations.
Also, isn’t the single DO a bottleneck?
And nice that you have composite indexes. Many relays don’t
Yes, you are correct that the current implementation of a single DO can present itself as a bottleneck since it’s single-threaded and caps at 1000 messages per second, but with queuing. However, I am currently working towards a multi-regional and/or a Pub/Sub coordinated integration that should help mitigate that. We’ll see how we go. The alternative would be to strip out the DO like before and not have stateful websocket. It’s been a fun project getting to trial various different methods and edge cloud tech.
