Cloudflare KV Cache-Warming Doesn't Work the Way You Think

Wed, 20 May 2026 00:00:00 +0000

Cloudflare KV Cache-Warming Doesn’t Work the Way You Think#

A common “obvious” optimization for Cloudflare KV: at the end of your deploy, write the top-N popular cache entries (search results, config blobs, computed views) so the cache is “warm” when production traffic arrives. This doesn’t do what you think.

KV writes go to central data stores only. Regional edges populate on first read in that region — and replication propagation adds up to 60 seconds. Writing from one Worker doesn’t push the value globally; subsequent first-reads in each region still pay the central-store fetch.

Cloudflare Vectorize Id 64-Byte Limit: The Hash-with-Metadata-Roundtrip Pattern

Wed, 20 May 2026 00:00:00 +0000

Cloudflare Vectorize Id 64-Byte Limit#

Cloudflare Vectorize caps vector ids at 64 BYTES, not 64 characters. The naive if id.length <= 64 skip-hashing check passes Unicode through and then fails at upsert time. The right pattern is unconditional SHA-256 hex hashing with the original id stored in metadata so query results round-trip back to your source-of-truth row.

TL;DR#

The limit is 64 bytes, not 64 chars. Multibyte UTF-8 hits it sooner than ASCII.
Always hash the id. Never branch on length.
Put the original id in metadata.id. Resolve back at query time.
A single oversized id fails the WHOLE batch — partial-success semantics.

The error#

VECTOR_UPSERT_ERROR (code = 40008): id too long; max is 64 bytes, got 67 bytes