After thinking a bit about it, I confess I have doubts regarding Storj for this use case. Though, not because of technical parameters of the Storj service, but the payment structure.
I would assume that the standard scenario for using S3 as a database storage, even if for less used data, is when deploying database on a cloud server, potentially close to the S3 service. within an AWS region (or within a region of a different centralized cloud service) data transfer is free, so querying data doesn’t incur additional cost and—even if slow—one can do that as many times as desired.
This is not the case of Storj, as data transfer fees are unavoidable. What’s more, Alexey’s recommendation of a 64MB block size makes it even more expensive. Assume a large table, going in tens of gigabytes. If a query can be satisfied by a transfer of a few scattered 4MB blocks, it will be faster to transfer and cheaper than the recommended 64MB blocks. Sure, full table scans will be faster with 64MB blocks, but also pretty expensive too.
It feels like Storj is close to being a nice candidate for this use case, yet S3 might be quantitatively better though right now.
I wonder whether having two tiers of pricing: one that is like the current one, another with no or very small egress costs, but more expensive storage, would make sense.