Durable Objects SQLite 儲存用量怎麼看：別把 namespace 圖表當成單一物件
Durable Objects 的 SQLite 資料量慢慢變大時，以前很容易只靠帳單或自己拉 GraphQL 指標才發現。Cloudflare 在 2026 年 7 月新增 Total storage 圖表，能在 Durable Object namespace 的 Metrics 頁面看見 SQLite 總儲存量的時間變化。
先講最重要的邊界：這張圖是 namespace 層級、每小時回報的最大 SQLite 儲存量；它不能告訴你是哪一個 Durable Object instance 佔掉空間。 因此它適合先確認「哪個 class 的儲存正在長」，不能直接當成資料清理的根因證明。
先確認你看的真的是 SQLite namespace
從 Cloudflare dashboard 進入 Durable Objects，選擇目標 namespace 後切到 Metrics。新的 Total storage 圖表只會出現在 SQLite-backed namespace；legacy KV backend 不會有這張圖。
這一點會影響排查起點：新 namespace 已應使用 SQLite storage，但既有 KV namespace 仍可能存在。若你看不到圖表，先回頭確認 class 的 storage backend，而不是先假設 dashboard 壞掉。關於新舊 backend 與 exports 的設定邊界，可先看 Durable Objects 改用 SQLite 與 exports 的設定方式。
Total storage 圖表能回答什麼，不能回答什麼
| 問題 | 圖表能否直接回答 | 下一步 |
|---|---|---|
| 這個 namespace 的 SQLite 用量是否持續成長？ | 可以 | 比對發布、流量或資料保留策略改動的時間點。 |
| 某次清理是否讓用量下降？ | 可以 | 選擇包含清理前後的時間範圍，觀察每小時最大值。 |
| 哪個 Object ID 或 name 佔最多空間？ | 不可以 | 從應用程式資料模型、日誌與個別清理工作回查。 |
| 單一 Object 的 request／error 是否異常？ | 部分可以 | 在 Metrics 以 ID 或 name 篩選其他圖表；不要把篩選結果誤當成 storage attribution。 |
Cloudflare 的 Metrics 文件說明，namespace 頁面可用 ID 或 name 篩選多數圖表；但 7 月新增的 Total storage 圖表仍不支援按個別 Durable Object 檢視。這兩個能力看似相近，實際上回答的是不同問題。
發現用量增加時，照這個順序縮小範圍
- 先記下 namespace 與時間窗：圖表預設看最近 24 小時；把時間範圍拉到上一次部署或資料清理之前，確認增加是持續趨勢還是一次性寫入。
- 比對程式與資料生命週期：檢查新增的索引、保留的事件、快取資料，或是否少了原本應執行的
delete()／deleteAll()工作。SQLite-backed storage 的 KV 與 SQL 資料都會佔用空間。 - 用 ID/name 篩選流量與錯誤：找出同一時段請求、錯誤或 WebSocket 活動特別突出的 Object，這是建立假設的線索，不是儲存量的歸因結果。
- 回到資料模型驗證：若應用程式本來就有租戶、房間或文件的識別值，可在應用程式日誌或 Data Studio 驗證預期的資料量與過期資料；不要直接刪除不明資料來讓圖表變小。
- 把門檻寫進維運規則：Free plan 的 Durable Objects SQLite 儲存總量有帳號層級限制，Paid plan 與單一 Object 也各有不同限制。門檻與告警數字要以目前方案和官方 limits 頁為準，不要從別人的 namespace 用量倒推出來。
圖表上升不是記憶體洩漏SQLite 儲存量與 V8 isolate 的 Memory usage 是兩個不同指標。Memory chart 量的是執行中的 isolate 記憶體，且可能包含同一 isolate 上的其他 Object；Total storage 則是 SQLite 儲存資料。先分清楚哪一條曲線異常，才不會用錯工具。
需要自動化時再查 GraphQL，不必先自己造儀表板
若 dashboard 已經能回答趨勢問題，先把檢查流程放進部署後或每週維運即可。需要跨 namespace、和自家事件對齊，或接既有 Grafana 告警時，Cloudflare 文件提供 durableObjectsStorageGroups 的 GraphQL 範例，能取回 storedBytes 指標。
自動化前先確認三件事：查詢的 account scope、資料時間窗，以及你要觀察的是最大儲存量還是其他聚合方式。圖表的用途是讓你看見變化；告警的用途則是讓維運人員能在變化超過自己的資料保留假設時採取動作。
Durable Objects 的新圖表把「這個 class 的 SQLite 用量有沒有異常」變成很快能回答的問題。真正的清理決策仍要回到資料模型、保留期限與可還原性，而不是只追求把曲線壓低。
參考資料：
Cloudflare Changelog：View total SQLite storage for Durable Object namespaces
回報錯字、失效連結，或告訴我你想看的延伸主題。