Tigris not on fly.io

[charsleysa]

Looking at tigris, all the information on the website leads me to believe that everything lives on fly.io infrastructure. However, I came across a message in another thread from @kurt which seems to contradict that.

@ovaistariq are you able to provide a clarification? What other infrastructure providers are used to store data?

[ovaistariq]

@charsleysa If you look at the architecture that is described in the docs here, all the components except for large object storage run exclusively on Fly.

Large object storage follows an intelligent model where we either use storage within Fly or we use remote storage (S3 or OCI depending on the proximity of their region to Fly region). Why do we utilize remote storage? We utilize it for the reason @kurt mentioned. As more and more storage capacity becomes available and large-storage-optimized hardware SKUs become available on Fly, the objects will move from remote storage to within Fly.

This is all transparent to the users in terms of the DX and pricing. At no point do you interface with remote storage directly because, as has been mentioned, the goal is to move whatever is stored outside of Fly’s infrastructure to within Fly’s infrastructure.

[charsleysa]

Thanks for the response!

@ovaistariq

If you look at the architecture that is described in the docs here, all the components except for large object storage run exclusively on Fly.

Large object storage follows an intelligent model where we either use storage within Fly or we use remote storage (S3 or OCI depending on the proximity of their region to Fly region).

I would recommend clarifying that as the documentation, especially this image, makes it seem like it’s all running on fly.io infrastructure which at the moment is not the case.

@ovaistariq

Why do we utilize remote storage? We utilize it for the reason @kurt mentioned. As more and more storage capacity becomes available and large-storage-optimized hardware SKUs become available on Fly, the objects will move from remote storage to within Fly.

This is all transparent to the users in terms of the DX and pricing. At no point do you interface with remote storage directly because, as has been mentioned, the goal is to move whatever is stored outside of Fly’s infrastructure to within Fly’s infrastructure.

I think this a completely reasonable approach. It’s no secret that fly.io block storage pricing is not optimized for lowest $/GB. There’s just a reasonable expectation to know that the data is not currently stored only on fly.io infrastructure (as is currently implied) due to the storage costs limitations.