KV has enough traffic everywhere that I don’t think you’re going to see cold loads of its worker
KV has enough traffic everywhere that I don’t think you’re going to see cold loads of its worker
HDo you mean the user’s Worker, or the 
Worker(?) that interfaces with KV?
Worker(?) that interfaces with KV?
UI'd be really surprised if the CDN doesnt cache files longer by plan level given the testing I have done of a free plan vs enterprise... the free plan caches data for a few minutes at low volume but it will cache data for hours on enterprise 
But I dont think ive ever seen it officially said from an employee fwiw so just people from the community have said it
But I dont think ive ever seen it officially said from an employee fwiw so just people from the community have said it
BI just confirmed with the cache team again. That is not the behavior today (may change at some point in the future if we want) - the cache is totally agnostic and the only thing that drives eviction is relative frequency patterns. ENT customers typically have more traffic on their zones and that’s why free gets evicted more quickly.
UGood to know 
SI see that 1M list requests are included in the paid plan. I also see that a list request has a default of 1k items, if I make a single list request and it returns the default 1k items does this count against billing as 1 list request or am I billed per key returned (1k)
H1 list request, regardless of the amount of keys returned
ZYup, I meant my worker of course.
DLet’s say I have a namespace with keys mapping to stringified objects, would it be worth it to shorten the keys of said objects to save bandwidth/storage costs?
De.g changing a key like "releaseDate" to "r". there are going to be quite a few entries so I’m not sure if this would help at all
UI mean with millions of items you will probably save a bit but it would make it really annoying dev wise so I wouldnt do it.
DWell I mean all it takes is a simple remapping function to map the stored shortened keys to readable keys
DI just want to know if I’m overoptimizing here, I mean it’s going to contain every movie/tv show on IMDb so
DYe alright, thanks
VDoes KV perform good when used via the HTTP API?
VIf I'm working in an environment where I can call the HTTP API or call a Worker which then uses service bindings which will be faster?
HFor production apps, I would generally recommend using a Worker, since the Worker KV API can be cached locally, while(iirc) the HTTP API has to hit core
EThe API is also rate limited
RI have next.js site on cloudflare pages. I want lowest latency. Each request is essentially a read + write both. Wondering what to use cloudflare kv or upstash redis.
Each key is associated to a user, so I only need read/write from closed point to user. Users are situated globally.
Each key is associated to a user, so I only need read/write from closed point to user. Users are situated globally.
UDurable objects would be the fastest if the user is only reading and writing their own key and no one else is
PCould someone help me understand some stuff in this part of the docs?
https://developers.cloudflare.com/workers/runtime-apis/kv/#parameters
Does this mean "concurrent writes to the same key"? Or just concurrent writes to any keys in general?
Can I store two values with different keys at the same time? One immediately after the other?
On the "How KV Works" page it says:
Implying that, so long as its the first Read in the location, it will reach out to the central data store and get + cache the value.
However, based on how the API docs are written, it implies that it could take up to 60 seconds for a "Write" to be visible globally.
Which is it?
i.e. what if the data or the key were too big? Are there other reasons it could fail not listed in the docs?
How do I catch and handle these errors?
On the
https://developers.cloudflare.com/workers/runtime-apis/kv/#parameters
Question 1:
Due to the eventually consistent nature of Workers KV, concurrent writes can end up overwriting one another. It is a common pattern to write data from a single process via Wrangler or the API. This avoids competing, concurrent writes because of the single stream. All data is still readily available within all Workers bound to the namespace.
Does this mean "concurrent writes to the same key"? Or just concurrent writes to any keys in general?
Can I store two values with different keys at the same time? One immediately after the other?
Question 2:
Writes are immediately visible to other requests in the same global network location, but can take up to 60 seconds to be visible in other parts of the world. Refer to How KV works for more information on this topic.This section is a bit vague at best, and at worst, conflicts with the "How KV Works" page.
On the "How KV Works" page it says:
Initial reads from a location do not have a cached value. The data must be read from the nearest central data store, resulting in a slower response.
Implying that, so long as its the first Read in the location, it will reach out to the central data store and get + cache the value.
However, based on how the API docs are written, it implies that it could take up to 60 seconds for a "Write" to be visible globally.
Which is it?
Question 3:
Will a.put ever "fail"? If so, what does it look like?i.e. what if the data or the key were too big? Are there other reasons it could fail not listed in the docs?
How do I catch and handle these errors?
On the
.put docs it says:This method returns a Promise that you should await on in order to verify a successful update.Does this mean I should expect an error if it fails? Or set it up with a
.catch or something?
CDoes this mean "concurrent writes to the same key"? Or just concurrent writes to any keys in general?Same key, you can write to different keys, not affected by that
Which is it?It's both, I don't see how those conflict, the first statement is a bit vague though. Writes update local colo (location) cache. If you write to ORD (Chicago), any KV Requests for that same key in Chicago will see the updated key instantly. If you had requested that key in EWR (Newark) recently enough that it is still in cache, it can take a minute or so to update to that new value, depending on when you fetched it. If you had never fetched that key from LHR, then a request frrom lhr would hit one of the central data stores and see the updated value instantly.
Note recently there was an update to decouple the background refresh rate from the cache ttl: https://blog.cloudflare.com/faster-workers-kv-architecture/
Question 3:
I believe yes on network exceptions and such edge cases where it just fails to write/confirm entirely, as well as usual validation of too long key/value. The method returns a Promise<void>, it would just throw an error like Type: Error, Message:
KV PUT failed: 414 UTF-8 encoded length of 1064 exceeds key length limit of 512.PThank you, that was very informative.
My clients are getting
Trying to track down what I've done wrong.
My clients are getting
404s when trying to access data that was just created.. but only sometimes.Trying to track down what I've done wrong.
PAnd if they retry the same request enough times, eventually they find it
PYes, now I do. I submitted a support ticket about it - would it be better to share my test project/info here?
EHey @phatso are you able to confirm the ticket number you raised? Wondering if it's the one I was on just now, or another
Mis there any way to push a keyvalue out to all edge locations and not have them expire? trying to check api keys for incoming requests
PYep! That's me
EHey 
do you have a link to the message you were referring to, so I can understand the context?
do you have a link to the message you were referring to, so I can understand the context?Dis there any way to get keys in bulk? googled but couldn't find anything
something like this:
something like this:
KNot with the Worker bindings, no
Dwhy is it available over http api but not worker bindings?
KI don't see it in the API either
KThere's bulk writes and deletes, but no gets.
Doh yeah i misread
Dthat's weird
Dwonder why
EI'm struggling with using kv, are there any good whole project examples. I see in the docs there is a tutorial for rust, but not ES. I'm just getting null when I call env.NS.get('whatever') and I'm sure it's got to be a setting so I'm looking for a whole working project to compare too. Thanks.
Khttps://developers.cloudflare.com/workers/runtime-apis/kv/#reading-key-value-pairs
getwill be
if that key doesn't exist.null
EThanks @kian - thing is, I can get the correct value from the command line "wrangler kv:key get --namespace-id=### "{key}" but it just doesn't in the worker.js. My binding has the same preview_id as I used in the commandline call. so I'll keep trying.
KIs it a published Worker?
KWrangler dev defaults to local development, so it has no access to your real KV namespace.
E@Kian oh. I did not see that mentioned in the docs. I'm using local. So is there a local kv to setup and use?
PMetadata only
EI did get it to work a bit but I still don't understand. I deployed, my wrangler.toml file has workers_dev=true yet the key value doesn't come from the namespace specified by preview_id
ESOLVED: I just needed to add --remote to the end of 'wrangler dev --remote' now I can read KV from localhost.
MHey, this announcement - https://blog.cloudflare.com/faster-workers-kv-architecture/#:~:text=If%20these%20sound%20like%20the%20killer%20features%20you%20need%2C%20please%20reach%20out%20to%20us%20if%20you%E2%80%99re%20interested%20in%20trying%20them%20out about new exiting features says that one can reach out and try out them earlier then ga - how can I do it?
The Cloudflare Blog
With the new architecture powering Workers KV our service will become faster and more scalable than ever. We have significantly reduced cold read probability, and enabled KV to serve over a trillion requests a month