Tigris global storage released a migration tool: shadow buckets

I think tagging per-object and bucket-level is both good to have. For bucket used by one app, it’ll be easier to do this on the bucket level, for a bucket shared across apps, this would likely be doing it on the object level.

1 Like

Thanks for the feedback @pmbanugo

This can be accomplished through eager caching which is documented here.

1 Like

Average size is 26KB, median 20KB. At the moment I am storing 310,831 short voice recordings and the number is expected to grow over time, possibly into millions if the project gains serious traction.

When it comes to the question of bucket-level vs object-level, it depends on what bucket-level would entail. A value that is set and tracked for each object as it is written or a value that is applied to the bucket as a unit, allowing you to dynamically add/remove replicas in Fly regions? The latter would be much more useful in my view.

A bucket-level setting would hopefully also work nicely with shadow buckets, so that I won’t need to populate the entire bucket and immediately incur the storage costs for 310k x 3 regions objects.

@nph This would be live replication tracked for every object. So, as objects get written, they are replicated async, similar to how replication works in a database system. I was thinking that bucket-level would provide a default value that will be used if not provided for individual objects.

Essentially, the feature we are implementing will allow you to control which regions you want the data to be stored in. The default behavior would be that Tigris automatically controls the region where data is stored, as is the behavior today.