Is it feasible to use Web3.Storage to perform Ceramic's IPFS needs?

The transition to ComposeDB includes the addition of a SQL store.

I was wondering if the Ceramic daemon itself writes anything to disk. If it’s just IPFS (& SQL) doing writes, is it feasible to use web3.storage to handle the IPFS interactions?

Google has their Cloud Run service which permits two million requests per month gratis. The issue is, persistent storage for it is complex and expensive.

Hey @dysbulic, I already replied on Discord but also replying here so the answer is searchable.

Using Web3.Storage actually seems like a very interesting idea, and based on their documentation, probably something that could work fairly easily, though it would need some changes to the Ceramic code for API auth.

The other component to consider would be the Ceramic state store, which, for the moment, can only be in AWS S3 or on the filesystem.

We have been discussing ways to make this more scalable, and keeping it in SQL definitely seems to be one possibility. This isn’t implemented yet but it’s coming up fairly soon on our roadmap.

w.r.t. cost, I would say we’re probably close to the number you quoted for GCP, considering 1 AWS ECS Fargate instance each for Ceramic and IPFS + S3 for storage, etc.

This is a difficult comparison to make well though - we’re using ECS Fargate but could be using cheaper EC2 instances, switch to Graviton processors, use the filesystem instead of S3, switch to SQL for the state store, etc.

There aren’t any canonical, optimized deployment models yet, so an apples-to-apples comparison of various deployment models across cloud providers isn’t quite feasible at the moment.

There are also a few other unknowns/variables to consider, e.g. IPFS bitswap can make a couple of orders of magnitude more “WANT” queries for data not locally available (and resulting in “DON’T HAVE” responses since individual nodes only pin the information they care about and not all the data on the network), which, if using something like S3 for IPFS storage, can increase the AWS bill.

I realize this isn’t super helpful for what you’re looking for :frowning:

I’m hoping though that people in the community will soon figure out cheaper, more optimized models, or just achieve some economies of scale as Ceramic node operators to bring down prices.