How to use Cloudflare KV in Base

Cloudflare KV is a key-value store at the edge: fast reads, eventually-consistent writes, ideal for data you read far more often than you write. Configuration, feature flags, cached results, anything you want available everywhere with minimal latency. Base wires KV into the same settings-and-injection model as the rest of your worker, so using it is declaring a connection and asking for the store.

What KV is good at

KV is not a relational database and is not trying to be. It maps keys to values, reads them quickly from anywhere at the edge, and accepts that a write may take a moment to be visible everywhere. That shape is perfect for read-heavy, write-light data: the settings your worker loads, the flags that gate a feature, a value computed once and read many times. It is the wrong tool for data you mutate constantly or query by anything other than its key. Knowing that boundary is most of using KV well.

How Base exposes it

You declare KV in your worker's settings, the same place you declare your router or your database. Once declared, the key-value store is available through Base's storage interface, which gives you the operations you expect: read a value by key, write a value, delete one. You reach the store the framework way, by asking for it, rather than touching a raw binding, so your code that uses KV looks like the rest of your Base code.

The operations themselves are deliberately simple, because KV itself is simple. Get a key, put a key, delete a key. The value of the integration is not a clever API on top of KV; it is that KV lives in the same configuration and injection model as everything else, so adding it to a worker is one declaration rather than a separate setup.

Caching with KV

One pattern Base supports directly is using KV as a result cache. Work that is expensive to compute and stable for a while (a rendered response, an aggregate, a lookup that hits a slower system) can be computed once and cached in KV under a key, then served from the edge on subsequent reads. KV's read-fast, write-rarely profile is exactly the profile of a cache, which is why it is a natural home for one.

The mental model to keep

KV in Base is edge key-value storage for read-heavy, write-light data: declare it in settings, reach the store through injection, and use simple get/put/delete by key. Lean on it for configuration, flags, and caching, where fast global reads matter and eventual consistency is fine. Reach for the relational ORM instead when you need queries, relationships, or strong consistency. KV is the fast, simple shelf; use it for the things that belong on a fast, simple shelf.