undefined | Better HN

0 pointskentonv5y ago0 comments

Workers KV is still better in many use cases. Durable Objects are the right choice when you need strong consistency. KV is the right choice when you want world-wide low latency access to the same data. Note that these two advantages are fundamentally opposed; it is physically impossible to simultaneously have strong consistency and worldwide low-latency access to a single piece of data. So, this will always be a trade-off.

Note that you could build KV on top of Durable Objects, by implementing your own caching and replication in application logic running in Durable Objects. On the other hand, you can't implement Durable Objects on top of KV; once you've lost strong consistency, it's hard (impossible?) to get it back. So in that sense, Durable Objects are "strictly superior". But in a practical sense, you probably don't really want to do the work to implement your own KV store on top of Durable Objects; it's probably better to just use KV.

0 comments

2 comments · 1 top-level

Scarbutt5y ago· 1 in thread

What's the size limit of a single 'Durable Object' ?

kentonvOP5y ago

There's no hard limit, but given that a single durable object is single-threaded, storing a huge amount of data in a single object may make it hard to access that data. Also, the system may be less likely to migrate huge objects to move them closer to their users. So, we recommend aiming for small, fine-grained objects, kilobytes to megabytes in size. But there's nothing fundamentally preventing an object from growing to multiple gigabytes.

j / k navigate · click thread line to collapse