Thoughts on Workers KV

Posted on February 13, 2020  •  2 minutes  • 311 words

Infrequent write / frequent read

I tried to build a todobackend.com with Cloudflare workers and Workers KV. However, the specs runner keeps failing, inconsistently.

Meaning they would pass this run and fail the next. Manual tests usually doesn’t have this problem. This tells me it seems Workers KV is not synchronous or the data replication is slow.

Turns out, it’s mentioned right there in the Workers KV’s docs; emphasises are mine.

Workers KV is generally good for use-cases where you need to write relatively infrequently, but read quickly and frequently. It is optimized for these high-read applications, only reaching its full performance when data is being frequently read. Very infrequently read values are stored centrally, while more popular values are maintained in all of our data centers around the world.

KV achieves this performance by being eventually-consistent. New key-value pairs are immediately available everywhere, but value changes may take up to 60 seconds to propagate. Workers KV isn’t ideal for situations where you need support for atomic operations or where values must be read and written in a single transaction.

With this, todobackend.com specs runner would never pass.

The Workers KV API is quite simple for now and I do hope they keep it that way, or maybe resemble Redis API with some more data types like list / sorted set. That would be lovely.

Batch load is not yet supported

It’s on roadmap but not yet available. So the result of .list() will have to be mapped with a Promise.all like this

await Promise.all(keys.map(key => myKvStore.get(key.name)))

With these limitations, Workers KV are more suitable for keeping build assets or anything that doesn’t need close-to-real-time propagation. Keep that in mind when you want to build something with Workers KV; also watch this space as Cloudflare is moving pretty fast.

Some other limits can be found here on Cloudflare workers docs .