Ah, thought R2 wasn't added yet to the terms

Has anyone tested the difference in TTFB between R2 and KV?

R2 could perform much better for worst case scenarios I think, KV has only 2 masters (Europe and US) and if your stuff isn't cached in the datacenter the first fetch travels to those, people measured 400ms+ latency in some cases.. I guess R2 is architected much more distributed, "cold cache" should perform better (I hope).. but just a guess

Woah that's great. So in which situations would we use KV, which charges $5 per GB?

KV charges $0.50 per GB, not $5

Whoops my bad

Still, R2 is priced at $0.015 per GB, which is 1/30th of the price. If it does perform better than KV, when is KV a good idea?

R2 is still a while away and even the dev team doesn't know what the final performance metrics will be for it under production load levels, so if you're basing it purely on that it's better to wait and see.

Alright, thanks.

KV is a different class of product, though. It's a distributed KV datastore, with some specific performance guarantees.

I was thinking about storing a small number of images (several thousand), so either R2 and KV could be used. I'm wondering which would be better for frequently accessed small blobs?

If you handle files, provided both are available, R2 is decidedly better suited (with caching added). KV requires base64 transformations, etc. which are a pain. Plus it’s more expensive.

I'm pretty sure you can put and read streams and blobs directly into and from KV, and also use the cache api with it

Yeah, Matteo was just saying that if you used R2 that you'd need cache as well. Not that KV doesn't have cache.

Ok cool. So then which would be faster on a cache miss?

Not sure, there's not many benchmarks around quite yet 😄

But R2 is more distributed than KV AFAIK. Not really much public info but I believe it's a bit more distributed than KV which only has US and Europe central locations.

Alright, thanks!

R2 is still being very actively worked on so cold read benchmarks aren't very representative currently. Since you'll have a Worker invokation either way (to grab from KV or cache R2) then R2 is probably the better choice. I do love KV though so you should also try that and just see which you prefer :p

Pages are currently built on top of KV, will it get any benefit from moving to R2?

(Speculation Inbound)Pages might benefit from moving some assets to R2, such as large downloadable files, images, audio, other assets etc., but for most things such as CSS/HTML/JS bundles, KV will always be faster to read from, and thus the go-to for most assets. But, this is totally up to the team, so we will see where it goes.

^^

Why is it that smaller items are faster in KV than R2?

In my head each data center should have their own cache anyways, KV or R2.

Copy-Pasted As far as I’ve seen from people testing it, and from intentions I have heard from the team, KV will still be(not accounting for the cache) the go to for DB-like and small files, as it’s underlying infrastructure makes it lightning fast to pull from origin colos. But, because of the way it is optimized, it just cannot support very large values at scale, so that is where R2 is better. But, as I said, just what I have scraped together, and may not actually be what is intended.

Oh I'm talking specifically in the context of Pages.

My assumption would be, past the first fetch, KV or R2 both will be cached in data centers anyways so there's no performance difference

So I'm thinking Pages could leverage R2 and relax the file size and file count limit.

File size limits could probably be increased, if not removed, by storing larger files in R2. The difficulty is that it looks like cold-read times for R2 are and will remain higher than KV, and thus the smaller files will probably still be stored in KV, even if others will utilizes the larger file limits of R2.

This seems to suggest the opposite?