I also want to add that as Tigris is S3 compatible, you could just swap out S3 with Tigris when using the volumes.
The use-case I’m interested in is apps that write their own code at runtime. For example, in WordPress you can use its web UI to install 3rd party plugins, which results in downloading their code and making that code now part of the app. In other words, the app code isn’t in the Docker image but instead in a persistent filesystem, such as a Volume. But, if you have multiple machines in multiple regions, these volumes need to be kept in sync. From what I read about Tigris, it seems like potentially a great solution for having a single object store that can maintain consistency regardless of where it’s read from while also providing low latency reads from all locations. However, for an app like WordPress, PHP needs to be able to read its code from a filesystem, not an S3 object store, so this post caught my interest. Also, PHP calls stat on each code file on every request, so I think there’d need to be some kind of a local cache to avoid excessive requests to Tigris. To summarize, this use-case doesn’t need the “bottomless” part, but could benefit from Tigris’s replication system.
The R2 buckets are created in some region closest to the client that’s creating the bucket and are not replicated worldwide (ref).
1 Like
This would be spectacular in combination with Barman for Postgres. Keep the backups in S3 and save a TON on volume pricing.
2 Likes
Yeah, that is a common misconception about R2. On the other hand a Tigris bucket indeed is distributed across the world and not tied to the region where it was created.