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#

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

This is a 4xx-class refusal at the upsert API. One bad id in a vectorize.upsert([...]) batch rejects every vector in the call — it is not partial-success-with-warnings. If you batch 100 vectors and one has a 67-byte id, all 100 silently fail to land.