Ah that's good to hear, thanks for linking that

As Isaac mentioned I was thinking about memory so it's not relevant to R2, but if it's workers in general see: https://developers.cloudflare.com/workers/platform/limits/#memory If you want to chat about it more it's probably worth moving to the #779390076219686943 channel

Yeah that is accurate about the memory. It's not specific to R2 but Workers can share memory if they're called from the same DC and at the same time.

It would be super legit if there was a TUS upload endpoint for R2.

The 500 MB limit for request body is documented here: https://developers.cloudflare.com/workers/platform/limits/#request-limits The 128 MB per Worker instance is documented https://developers.cloudflare.com/workers/platform/limits/#memory but it's listed in many places throughout. The architecture about isolates and how each one processes requests is described at https://developers.cloudflare.com/workers/learning/how-workers-works/ Workers can definitely process requests that are > 128 MB of body. The thing to watch out for is that your instantaneous memory usage allocated per request is kept bounded so that your isolate doesn't exceed the 128 MB limit if you handle a lot of requests simultaneously. The memory we'll see a worker is using is going to be approximately

# of outstanding requests for that worker * max memory allocated per request

.

very curious to find out what kind of bandwidth can be achieved pulling data from multiple R2 objects simultaneously into a non-worker destination

What's the speed you get from speed.cloudflare.com?

749Mbps / 31.1Mbps / 20.4ms / 3.71ms

Why i dont get the next destination?

Depends on your ISP and how they peer with Cloudflare. Some ISPs have strange peering... I get routed to a colo 800km further than my closest one 🤷‍♂️

wtf

Theoretically pulling 1 file should be able to saturate your available link to Cloudflare but we haven't profiled it yet so 🤷‍♂️ . Pulling multiple files concurrently should be able to saturate that. This assumes large files (for some definition of large) where the latency of the request is insignificant. For small files (for some definition of small) you'll need to have a LOT of concurrent requests going. It's hard to predict arbitrary performance questions. My best advice is to wait till you have access/Open Beta & try it out? Happy to discuss specific scenarios.

Will R2 support moving/renaming files and folders? Right now in S3, you have to copy and delete each file.

You're correct about S3 but they abstract it away in the UI in case you weren't aware, there's a Rename Object button that does that behind the scenes.

Sorry, I should have been more clear. I was thinking more about cost, so on s3, renaming a big folder means sending a copy request for each file in it (iirc) which could get expensive. Will R2 be like this as well?

i guess how expensive that will be will depend upon what the per request pricing ends up being

> R2 will zero-rate infrequent storage operations under a threshold — currently planned to be in the single digit requests per second range. Above this range, R2 will charge significantly less per-operation than the major providers.

if the per-operation price is sufficiently low, then "renaming" a folder might be negligible. i don't think any per-operation prices have come out yet, correct?

I guess we'll have to wait and see. It would be nice if we could move/rename an entire folder with one request though.

yeah it's just not something that goes well with the way object storage is typically architected. objects (and even portions of objects) along with their names are usually very heavily distributed via sharding

which is great for scalability but things like "fast atomic renames of an entire set of objects" isn't really practical without introducing complexity that likely would compromise said scalability some kind of sharding-aware rename operation is probably feasible but i'm not sure it'd be worth it

Copy + delete should work and (unless I'm mistaken) since delete is 0-rated it's just the cost of 1 write. However, that's not actually a strongly consistent operation. An atomic move of an object is easy for us to implement, we just haven't yet. It's already on the backlog. Moves of folders is more challenging. Nothing we can do that's as trivial as a folder "move". We could offer a list-like API to do the rename of objects within a folder. That would be billed at write rates but operate with list-like performance (i.e. 1k objects per request and you get back a continuation token).

@User would that list-like behavior work for you?

That sounds great! So no avoiding paying the write rate for each object?

From what I'm reading it looks to me it's still one write per object...

Alright, makes sense. Pretty darn cheap anyway haha

I don't know what the billing on a hypothetical API would be.

Is R2 close to public beta?

thats one of the questions on the qna