Doing some research on Ceramic vs. IPFS/Arweave for a project I’m working on. Curious to know if there’s any optimizations done at the data layer that would make Ceramic a more performant solution than using IPFS. Is there any documentation around this?
1 Like
Hi @rahul, thanks for your post and apologies for the super delayed response 
To answer your question, I would step back and ask what it is you’re trying to achieve. Ceramic provides a very different set of features and data access patterns than IPFS/Arweave.
The latter are more for decentralized storage, while Ceramic relies on decentralized storage to provide (among many things):
- Decentralized identity primitives based on DIDs, session keys, object capabilities, SIWx, etc.
- A decentralized, composable graph database.
Does this answer your question?
Thanks, Mohsin! It definitely provides some clarity.
My use case fits into the second bucket (decentralized database). Any documentation I can read on how this is implemented on top of IPFS/Arweave?
Hey @rahul, apologies for another long delay in getting back to you. I was out the last several days and just got back 
I promise that delayed responses is an anomaly and not a habit.
We don’t have anything on Arweave at the moment and our usage of IPFS is quite straightforward.
Here’s the spec for how one of our older stream types is stored on IPFS. Documentation for newer implementations is still in the works, but the TileDocument spec will give you an idea of how we typically use IPFS for storage.
The graph database uses newer stream types (e.g. ModelInstanceDocument) but the principle is the same.