Consistency model is probably the main 'it depends'

KV is good for read-heavy where you're okay with eventual consistency, whereas a DO is a single, unique object which means you have strong consistency but latency for cross-region requests.

D1 is SQLite on DOs, so you get the same consistency model (and latency downside), but will eventually give users read replicas to offset the latency hit (but likely also incurring eventual consistency for those replicas)

There's also R2, which is strongly consistent and similar to S3 - but has Worker bindings just like KV

yeah I was skimming KV docs last night and my brain just registered "don't use this if reads/writes happen less frequently than 60s"

Personally I would use R2 - since it has an S3 API, there's already a wide ecosystem for interacting with it outside of Workers (i.e backups) - but there is the performance constraints that you have to consider.

or use a DO as a sort of consistent index, and store the data in KV?

KV's cache/timings/etc will be changing in 2.0 - https://discord.com/channels/595317990191398933/874727019479437372/1087242463976108052

You'll have a lot more options to make it workable for different workloads (or consistency needs)

Note that with all of these products, you are OK to use the Cache API to store them at a given edge colo where the Worker was requested

so if they're read frequently enough, you can usually not feel the cold read of DO/R2

hmm, hadn't considered adding cache into the mix 🤔 that's a helpful suggestion! Thx https://developers.cloudflare.com/workers/runtime-apis/cache/?cmdf=cloudflare+cache+api

R2 being able to leverage S3's ecosystem is IMO most important for data durability - even if we discount the idea that Cloudflare has a data loss incident, that will never protect you (or someone else) accidentally deleting data. R2 is very easily backed up onto

It'll also have object versioning, and just recently got lifecycle rules - both concepts from the S3 world as you're probably used to

yeah, don't know why I didn't think of R2. That seems like a good starting point (because S3 compat)

there's a lot of breadth there

If D1 fits your needs, it also has hourly backups to R2 - but yeah, I love R2 just for the S3-compat and concepts.

Not to mention 5TB max object size, etc - you probably won't need anything near that, but the ceiling is a lot higher than the other options.

It's also the cheapest - for reads, you can expose it on a custom domain that uses caching w/o any Workers involved

heh, yeah, for the projects I'm working on now I'll be high-fiving someone if an object gets to 5GB haha

R2 buckets are currently single region - with stuff like replication (or moving data near where users request it most, or however the team decide to implement it) on the roadmap

They get created closest to you when you create it (GeoIP) but you can provide a location region yourself if you'd prefer to place it closer to

As I'm sure you can guess, I have a clear favourite - the S3 API gives me a gateway to data durability and portability that only D1 really comes close to (automatic backups and sql dumps)

any idea for what the pricing model for sockets would be? if I have an socket ex. game server open for 1 minute, will i be billed for the entire minute?

I just noticed this upon new bucket creation. Seems like something that can be mitigated w/ Cache API and/or other means.

Is it still possible to use WASI?

I assume so

not sure whether its documented outside of this repo and the accompanying blog post