Buckets (and on the object-level I believe) is dictated by where the bucket was created, or object w

Buckets (and on the object-level I believe) is dictated by where the bucket was created, or object was uploaded.

So yeah, whilst the cache exists in every colo (all 350+ of them) and R2 has a lot fewer points of presence, there's lots of performance improvements on the way with R2.

kianOP•7/13/22, 12:19 AM

If most of your users are in the EU, then create bucket/upload objects from there & that fun stuff

kianOP•7/13/22, 12:20 AM

r2 is a good write-up by Vitali on the current 'status' of R2 and where it's at with durability/availability/performance with performance being the current focus

kianOP•7/13/22, 12:20 AM

kianOP•7/13/22, 12:20 AM

fwiw my betteruptime for Workers R2 bindings

kianOP•7/13/22, 12:22 AM

R2 is strongly consistent - you write, you read straight after, everyone sees the new value. That does make it a lot more difficult to have global replicas of data than something eventually consistent... like KV!

Workers KV is eventually consistent & cached (not the same cache we've been talking about), so that's good for write-once read-many scenarios if you're OK with global replication possibly taking 60 seconds or more. Cold reads might be around ~130ms, the same I'm getting from my R2 bucket, but once that key is 'warmed up' and in KV's cache then the reads are a lot faster at like ~20ms.

kianOP•7/13/22, 12:23 AM

They do have different use-cases though (aside from the consistency) - R2 is your normal blob object storage, with object sizes up to 5TB whereas KV is limited to 25MiB.

kianOP•7/13/22, 12:36 AM

Kate will know how to word it - Kate always knows

Kkian Buckets (and on the object-level I believe) is dictated by where the bucket was ...

Cat smoocher•7/13/22, 12:40 AM

For my usecase, i'd really just need to store and serve user uploaded images. The rest of my data lives in Google Firestore. I like the idea of not having to pay egress and all the other fees that S3/Google Storage would definitely require so r2 seemed like it could be a good fit. I did see that CF also has an Image service aPES_Think

If I just need to exclusively store/serve images, could that be a better solution? What are your thoughts?

Although given the improvements being planned for r2 and the response times you sent, it doesnt seem like the inability to "cache" is a big deal for me...maybe. I really dont know enough about CDN/caching to know if it's going to be a big enough impact to me. I dont have any benchmarks or real data since I'm still building my site out

kianOP•7/13/22, 12:44 AM

Images: fully managed image pipeline. Images are stored there and you can create variants for resizing, cropping, next-gen formats like WEBP and AVIF, compression. Like Imgix.

Pricing model: per image stored and per image delivered

Image Resizing: Similar to Images except your files can be stored wherever - IR just provides on-the-fly transformations like the above ones that Images can do.

Pricing model: per cache miss on a resized image, IR has its own cache.

KV: eventually consistent global key-value store up to 25MiB, like Redis - would serve your raw image

Pricing model: storage and operations, only realistically usable with a Worker so Worker requests

R2: strongly consistently object storage, like S3 or GCS - would serve your raw image

Pricing model: Ditto KV but public buckets are on the way

kianOP•7/13/22, 12:45 AM

Features like Polish will already compress and turn images into WEBP on your website - so maybe the transformations aren’t that valuable.

kianOP•7/13/22, 12:45 AM

It’s all up to you, and also planning for scaling - would you eventually allow arbitrary user uploads which might be big enough to need R2? Will you be OK managing KV for smaller files and R2 for bigger ones, or would you rather merge it?

kianOP•7/13/22, 12:57 AM

R2 also has a much more generous free tier if that matters to you

kianOP•7/13/22, 12:57 AM

KV has 1GB, 30k writes, 3.0mil reads (approx) and R2 has 10GB, 1.0mil writes and 10.0mil reads (approx) on their free tiers

Cat smoocher•7/13/22, 12:59 AM

you read my mind happycat

Price is probably one of the more important factors for me since I'm a team of 1 haha. That's what attracted me to r2. Images and the resizing functionality seemed really slick, but I think it could get expensive unexpectedly compared to r2.

kianOP•7/13/22, 1:00 AM

Images has a sourcing kit feature where you can import images from S3/R2 so you can always easily migrate in the future

Cat smoocher•7/13/22, 1:07 AM

good to know, thank you! I may start messing with r2 and CF Images both to see what feels better. I suppose I wont really know what solution fits me better until I get real traffic and users PES_Think

kianOP•7/13/22, 1:11 AM

Workers is free for 100,000 reqs a day and that’ll never exhaust the free tier (reads) of R2 - so stay under 10GB in R2 and it’ll be $0 overall

Cat smoocher•7/13/22, 1:19 AM

thanks for all the help PES_Happy

kianOP•7/13/22, 1:20 AM

Kkian I'm not good at wording - `Beta Feature Implemented`, `Feature Implemented in Be...

Karew•7/13/22, 2:00 AM

What about:

Feature Implemented

Feature In Beta (maybe buggy)

Not Implemented

beelzabub•7/13/22, 2:05 AM

I personally don't like "may be buggy". I feel like it delivers the wrong message. Bugs always exist & features we release generally have a pretty good quality bar already (even ListMultipartUploads). "Work in progress" or "Details in flux" is probably a better description of what's happening. The main change we're making is to get the upload ID to be stable (i.e. the same one as when you ). The next thing we're thinking about is whether has behaviors that are technically required but that no one actually cares about in practice. My hunch is the latter

Isaac McFadyen•7/13/22, 2:05 AM

How about:

Feature Implemented

Feature Implemented (may change before stable)

Not Implemented

Karew•7/13/22, 2:05 AM

Maybe something like

Just Released (feedback welcome), then?

Karew•7/13/22, 2:06 AM

Just Released (unstable)

beelzabub•7/13/22, 2:36 AM

https://tenor.com/view/shed-garden-shed-shed-outside-storage-gif-12362549

Tenor

Shed

beelzabub•7/13/22, 2:36 AM

Bikes go in there

andrew•7/13/22, 6:38 AM

just curious, any ETA on the R2 transition tool that auto-pulls from another bucket and populates the R2?

Aandrew just curious, any ETA on the R2 transition tool that auto-pulls from another buc...

beelzabub•7/13/22, 1:09 PM

No. We’re still trying to figure out the product. My guess is sometime after GA.

Aandrew just curious, any ETA on the R2 transition tool that auto-pulls from another buc...

kianOP•7/13/22, 1:10 PM

FWIW you can easily do this with Workers (migrate from S3 to R2 on request) if you're intending for your R2 files to be publicly accessible - otherwise stuff like or

rclone

rclone

can do it pretty well in bulk up-front

Original message was deleted

beelzabub•7/13/22, 1:11 PM

I thought you could already but I guess it’s per bucket? If so then I imagine we will at some point. Thanks for the feedback. I’ll write it down

Jjsdk9527 Here is my worker code

kianOP•7/13/22, 1:11 PM

You'll want to return the in your

GET

GET

case when constructing the new response.

kianOP•7/13/22, 1:12 PM

Jjsdk9527 Here is my worker code

beelzabub•7/13/22, 1:12 PM

You’re saying the Workers API throws an exception that says the file is corrupted?

kianOP•7/13/22, 1:13 PM

Oh, that'll be unrelated to what I posted then - but you should still add that in for when you're accessing the image via your Worker's URL

Jjsdk9527 The downloaded file cannot be opened

beelzabub•7/13/22, 1:14 PM

So just checking to make sure I understand. Reading the file via Worker is fine. But you can’t download in the UI?