Cloudflare 不再讓新帳號建舊式 Durable Objects：新建一律改用 SQLite 儲存

一句話看懂：Cloudflare 從 7 月 9 日起，沒有舊式儲存的帳號新建 Durable Object 只能用 SQLite，繼續寫舊設定會部署失敗。

先用白話講：Durable Objects 是什麼？

想像你開了一間連鎖早餐店，每個客人都有一個專屬的小置物櫃，裡面放他的點餐紀錄。Durable Object 就像這樣的櫃子，只是它在 Cloudflare 的全球機房裡：每個物件有自己的程式、自己的記憶，同一時間只有一個人在用，適合做聊天室、計數器、線上協作這類「需要同一份資料不被搶著改」的服務。

這些櫃子裡的資料要有個存放方式，也就是「儲存後端」。以前有兩種：舊的鍵值（KV）後端，像一張只能「用名字查東西」的便條紙；以及後來的 SQLite 後端，像一本可以用 SQL 語法查詢的小資料庫。

發生什麼事

Cloudflare 在 7 月 9 日的更新日誌宣布：

• 如果你的帳號還沒有任何鍵值版的 Durable Object namespace，之後就不能再建新的了
• 新的 namespace 一律要用 SQLite 後端，官方說這從 2024 年正式推出後，就一直是新物件的建議做法
• 已經有鍵值版 namespace 的帳號，目前還能繼續新建；Workers 免費方案本來就只支援 SQLite 版

換句話說，這次是「把舊路封起來」，還不是強迫舊物件搬家。

對你的專案有什麼影響？

官方也說，這是「讓 SQLite 成為 Durable Objects 唯一儲存後端」的一步，之後會再提供既有鍵值版物件的遷移路徑。細節目前官方沒有公布，建議追蹤他們的文件。

SQLite 版有什麼好處？

官方的說法是：SQLite 版與鍵值版功能對等，原本的鍵值儲存 API 照樣能用，還多了兩樣：

• 可以用關聯式的 SQL 語法查詢資料
• 可以把物件的儲存內容，還原到過去 30 天內的任何一個時間點

後者很實用：如果程式寫錯、不小心把資料蓋掉，有機會回到出錯之前，不必自己另外做備份機制。

給開發者的技術細節

建立新類別時，要在遷移設定使用 new_sqlite_classes：

{
  "migrations": [
    { "tag": "v1", "new_sqlite_classes": ["MyDurableObject"] }
  ]
}

• 如果在受影響的帳號上用舊的 new_classes 建新的鍵值版 namespace，部署會失敗，錯誤訊息大意是「這個帳號不再支援建立新的鍵值版 Durable Object namespace，請改用 new_sqlite_classes」
• 只有 SQLite 後端的類別才能使用 SQL API 與時間點回復
• 不用急著改舊程式，但團隊的專案範本、CI 部署腳本，最好現在就檢查一次有沒有寫死 new_classes

我的看法

我自己的感覺是，這個改動對多數人其實是好事。以前新手看文件常會搞不清楚該選哪一種後端，現在只剩一個答案，選擇障礙就沒了。而且 SQLite 版多了 SQL 查詢和時間點回復，做小型服務時省下不少自己寫查詢、做備份的力氣。

要小心的反而是接案或維運多個專案的人：如果手上有舊範本，新開的帳號或新客戶環境套用下去，可能剛好踩到「部署失敗」。建議把範本裡的遷移設定一次改好；另外，真正的遷移辦法官方還沒公布，既有的鍵值版物件先別動，等正式文件出來再評估。

名詞小辭典

• Durable Object：Cloudflare 提供的一種有狀態的小程式，每個物件有自己的資料，同一時間只由一處執行。
• 鍵值儲存（KV）：用「名字對應內容」存資料的方式，像字典，只能用名字查。
• SQLite：一種輕量的關聯式資料庫，可以用 SQL 語法查詢，這次成為 Durable Objects 的新建預設與唯一選項。
• 遷移（migration）：在設定檔裡告訴 Cloudflare 要新增、改名或刪除哪些 Durable Object 類別的步驟。

資料來源

• Cloudflare Changelog（2026-07-09）
• Cloudflare Durable Objects 儲存文件