I’ll try this one out tomorrow. Serialising/ Deserialising from ReadableStream should be fine
I’ll try this one out tomorrow. Serialising/ Deserialising from ReadableStream should be fine
TYou should probably store it as a string and then read it with json. Check out the new KV examples, this is one where a list of translations are stored https://developers.cloudflare.com/kv/examples/workers-kv-to-serve-assets/#:~:text=Default%20to%20English-,const,-translations%20%3A%20%7B (could have more depth there, as much as you want)
Cloudflare Docs
Example of how to use Workers KV to store static assets
STrue, If there is no performance penalty,
json.Stringify is what I'll go with . Thanks for the example, they are helpful.SIt worked and is pretty fast. I have 2 follow-up questions:
1: I uploaded a json to KV under
1: I uploaded a json to KV under
_preview KV dashboard. How do I get it available locally? I run npx wrangler dev —remote. - Is there a way to clean the stale KV values, using some cron type job?
TThere are going to be 3 'envs' for KV. 1 is prod, 1 is preview, 1 is local. the prod is when your worker is deployed. the preview is in cloudflare when you are running
npx wrangler dev --remote. the local is when your worker is running only locally npx wrangler dev. each is independent and you would need to write data in any of these dev modes to get data in thereTyou could technically make the preview id and the production id the same for development as long as you are aware that you are using your production env with
npx wrangler dev --remote, this is quite dangerous which is why the preview namespace is the defaultTFor stale kv values, you should look at https://developers.cloudflare.com/kv/api/write-key-value-pairs/#expiring-keys or https://developers.cloudflare.com/workers/configuration/cron-triggers/ for cron jobs
Cloudflare Docs
Enable your Worker to be executed on a schedule.
Cloudflare Docs
To create a new key-value pair, or to update the value for a particular key, call the put() method of the KV binding on any KV namespace you have bound to your Worker code:
MIs there a way to purge a complete namespace?
I periodically refresh my D1 database (full import) and in that use case I want to purge the full namespace that I use as cache before D1
I periodically refresh my D1 database (full import) and in that use case I want to purge the full namespace that I use as cache before D1
PI'm new to the Cloudflare environment. I would like to know how can I export all the KV data from an account to a file. We need to do some migration at work.
RHi, I'm having an issue deleting keys from the dashboard. Getting "remove key: 'Endpoint is unknown.'" Is this a known issue?
Mhas anyone tried using KV with better-auth's secondaryStorage? it seems pretty straightforward
just wondering if there are any gotchas or drawbacks I should be wary of?
just wondering if there are any gotchas or drawbacks I should be wary of?
Shello here, I can't find correct information online, is the list() function performant, or should I implement some sort of indexes inside an object instead of relying on list() ?
Susecase can be simplified as, I have a 1 customer with 3 orders, I want to get the 3 orders: should I do
list(customerId) and then 1 getget(customerId-index) and then the 1 get eachSI believe that is important question for performances and there should be some hint in the documentation for that
SGood morning! nobody here? 
IList is performant, yes.
Sthanks @Isaac McFadyen
IAlso probably good to keep in mind that List can see metadata so if your data is small enough it might be worth putting into metadata so you don't need a Get for each one: https://developers.cloudflare.com/kv/api/list-keys/#optimizing-storage-with-metadata-for-list-operations
Syes read that but I read a blog post (old) that was stating GET was around 20-30ms and list 200ms (x10) so I got scared
IHmmm possible it's not cached actually (get is cached). I assumed it was but maybe not?
IDocs don't say... if anyone else can confirm/deny then it might be a good docs addition.
Sthat'd be awesome to have real value here, and answer from CF yes!
LThat blog post is fairly old. Cold read latency for lists is lower than 10x GET latency at P99, but absolute latency values for you depend on your location as cold reads come from central stores, and also depend on how many keys you requested.
IIs List cached or no?
LIt is. Each listing page is cached iirc.
Scool thanks guys!
SIs there an ongoing incident with KV? Getting 500s from workers->KV
SIs Cloudflare KV a good option for low-latency needs, should I use it in Next.js and NestJS? We need to add it directly; we can't use the KV because it's causing latency. Is there any way to avoid this?
L
Hi, I have a question about Metrics and how to interpret them. OI the image, there is read latency of our KV store. Is this correct interpretation?- P99 390ms: means that 99% of read operations are done under 390ms
- P50 18ms: means that 50% of read operations are done under 18ms
UAnyone seeing latency issues in KV?
Cnot really
Cthe chart to the right of that is more interesting, how many cold reads do you have? Are you setting cacheTtl higher where you can/have a lot of infrequent keys?
UThanks @Chaika I'm not using cacheTtl, I will set it now and see.
this is my read status chart
this is my read status chart
Cgood amount of cold reads. KV only has two actual backing stores/locations, one us and one in the eu, it's then cached everywhere else. Cold reads are expensive
Raising cacheTtl at the cost of consistency can help if it fits your use, or in general aiming to hit a few frequent keys rather then many infrequent
Raising cacheTtl at the cost of consistency can help if it fits your use, or in general aiming to hit a few frequent keys rather then many infrequent
YIf you don't need workers and want to use KV, you can only use HTTP, right? The interface request limit is too low.
HYes. KV is really meant to be used with Workers. In the event you don’t want your program logic on Workers, I would still recommend using a Worker to do the actual reads/writes against KV, as it should be a lot more performant than using the default HTTP API
YBut it's really difficult for workers to restrict the development language
HWhat do you mean?
AIs this because of the connection overhead of using the HTTP API? And is it mitigated for writes if you’re using bulk writes?
TYes, it's actually because the HTTP API includes both control plane operations (create resources in Cloudflare) and data plane operations (write, read on KV for example). We're working on removing the API rate limits entirely because KV itself does not need to be rate limited
TSo today, if you use bulk operations, you can definitely do more operations against your KV namespace than with individual operations
1Is the removal of the API rate limit just for the KV endpoints? Or is there a more general discussion around removing that limit altogether
Psome people put the Cache API in front of KV to reduce read costs, and it's still very fast (not sure if faster tho)
Puse whatever works
Puse kv as the persistent backend that the cache api will pull from