Workers KV Instant 改用 Quicksilver，讀取 p99 從 287ms 降到 1.62ms
Cloudflare Blog · 2026-10-01 · 私有 beta
Cloudflare 把 Workers KV 的底層從「中央儲存加邊緣快取」換成內部的 Quicksilver 全球複寫儲存，新模式叫 Workers KV Instant，用「每個 namespace 每秒一次寫入」的限制換來幾乎即時的全球一致。官方數字是 p99 讀取 1.62ms，舊的 classic 模式是 287ms。
這項功能 2026 年 10 月 1 日以私有 beta發布，需要申請才能使用；同一套 get()、put()、list()、delete() API，但行為有三處不同。
原本的問題
Workers KV 自 2018 年推出以來，讀取要看邊緣快取有沒有命中。快取沒命中的冷讀要回到後端儲存，文章給的 classic p99 讀取是 287ms。寫入則要複寫到各個儲存後端，p99 寫入複寫超過 4.38s。
更麻煩的是一致性：更新靠 TTL 過期才會在各地生效，是最終一致。想在發表會當下把某個旗標打開，各地邊緣不會同時看到新值，只能等。
Quicksilver 是什麼
Quicksilver 是 Cloudflare 2020 年起用在內部的 key-value 儲存，目標是極快的全球複寫與低延遲讀取，文章說幾乎每個進到 Cloudflare 的請求都會對它做查詢。Instant 模式就是把這套系統直接開放給 Workers KV 的使用者，背後用的是Quicksilver v2。
核心改動
Instant 模式下，資料複寫到所有邊緣節點（文章寫發布時超過 300 個），中位數約 250ms；讀取不再依賴 TTL，更新後全球「立即可用」。p95 讀取以微秒計，文章稱讀取比 classic 快 100 倍以上。
| 指標 | Instant | Classic |
|---|---|---|
| p99 讀取 | 1.62ms | 287ms |
| p95 寫入複寫 | 181ms | < 1s |
| p99 寫入複寫 | 256ms | 4.38s |
建立 namespace 時要明確指定 "mode": "instant"，既有 namespace 不會自動變成這個模式。
代價與限制
這不是單純的升級，寫入限制反而更嚴：classic 是每個 key 每秒一次寫入，Instant 是每個 namespace 每秒一次，文章把原因歸結於 Quicksilver 只有單一 system of record 的架構。
- 不支援 metadata，
getWithMetadata會回傳 null。 list一次回傳 namespace 內所有符合的 key，沒有分頁。- key 最大
300bytes；整個 namespace 上限1 MB、最多10,000組 key-value。
價格也往「讀多寫少」傾斜：讀取（Class B）每百萬次 $0.20，classic 是 $0.50，便宜 60%；文章表示寫入與儲存則明顯貴很多。寫入與儲存的單位在擷取的頁面文字中有歧義，實際費率請以官方頁面為準。
影響範圍
適合的是每個請求都要讀、但很少改的小型設定：功能旗標、維護模式開關、路由表、封鎖名單。文章舉的例子是在發表會上切換 new-product-launched 旗標，讀取近乎零延遲，更新全球立即生效。
不適合的是把 KV 當資料庫用的程式：
- 用
getWithMetadata存版本或過期時間的程式，遷移前要改掉 metadata 的用法。 - 靠
list游標分頁遍歷大量 key 的程式，在 1 MB、10,000 組的上限下本來就放不進去。 - 每秒會對同一個 namespace 寫入多次的程式，會撞到 namespace 層級的寫入限制，要先合併寫入或拆成多個 namespace。
// classic：預設行為，依 TTL 最終一致
// instant：建立 namespace 時指定
{ "mode": "instant" }文章未公布 GA 時間，也未說明 classic namespace 能否原地轉成 Instant，目前只能確定要重新建立 namespace。
原始來源：Introducing Workers KV Instant、Quicksilver v2、Workers KV API 文件